﻿<!DOCTYPE html>
<html lang="en">
<head>
<title>JSON-LD 1.1</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<script type="text/javascript" src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
<script type="text/javascript" src="../common/common.js" class="remove"></script>
<script type="text/javascript" class="remove">
//<![CDATA[
  var respecConfig = {
      // extend the bibliography entries
      localBiblio:            jsonld.localBiblio,

      // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
      specStatus:             "CG-DRAFT",
      // if you wish the publication date to be other than today, set this
      //publishDate:          "2013-11-05",
      copyrightStart:         "2010",

      // the specification's short name, as in http://www.w3.org/TR/short-name/
      shortName:              "json-ld11cg",
      subtitle:               "A JSON-based Serialization for Linked Data",

      // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
      // and its maturity status
      prevVersion:            "https://www.w3.org/TR/2014/REC-json-ld-20140116/",
      previousPublishDate:    "2014-01-16",
      previousMaturity:       "REC",

      // if there a publicly available Editor's Draft, this is the link
      edDraftURI:             "https://json-ld.org/spec/latest/json-ld/",

      includePermalinks:      true,
      noRecTrack:             true,
      doJsonLd:               true,
      testSuiteURIkey:        "https://json-ld.org/test-suite/",
      postProcess:            [internalizeTermListReferences],

      // if you want to have extra CSS, append them to this list
      // it is recommended that the respec.css stylesheet be kept
      // extraCSS:             [],

      // editors, add as many as you like
      // only "name" is required
      editors:  [
        { name:       "Gregg Kellogg",
          url:        "http://greggkellogg.net/",
          company:    "Spec-Ops",
          companyURL: "https://spec-ops.io/",
          w3cid:      "44770",
          note:       "v1.0 and v1.1" }
        ],

      // editors, add as many as you like
      // only "name" is required
      formerEditors:  [
        { name:       "Manu Sporny",
          url:        "http://manu.sporny.org/",
          company:    "Digital Bazaar",
          companyURL: "https://digitalbazaar.com/",
          note:       "v1.0" },
        { name:       "Markus Lanthaler",
          url:        "http://www.markus-lanthaler.com/",
          company:    "Graz University of Technology",
          companyURL: "http://www.tugraz.at/",
          note:       "v1.0" }
        ],

      // authors, add as many as you like.
      // This is optional, uncomment if you have authors as well as editors.
      // only "name" is required. Same format as editors.
      authors:  [
        { name:       "Manu Sporny",
          url:        "http://manu.sporny.org/",
          company:    "Digital Bazaar",
          companyURL: "https://digitalbazaar.com/",
          note:       "v1.0" },
        { name:       "Dave Longley",
          url:        "https://digitalbazaar.com/",
          company:    "Digital Bazaar",
          companyURL: "https://digitalbazaar.com/",
          note:       "v1.0" },
        { name:       "Gregg Kellogg",
          url:        "http://greggkellogg.net/",
          company:    "Spec-Ops",
          companyURL: "https://spec-ops.io/",
          w3cid:      "44770",
          note:       "v1.0 and v1.1" },
        { name:       "Markus Lanthaler",
          url:        "http://www.markus-lanthaler.com/",
          company:    "Graz University of Technology",
          companyURL: "http://www.tugraz.at/",
          note:       "v1.0" },
        { name:       "Niklas Lindström",
          url:        "http://neverspace.net/",
          note:       "v1.0" }
      ],

      github:    "https://github.com/json-ld/json-ld.org/",

      // name of the WG
      wg:           "JSON for Linking Data W3C Community Group",

      // URI of the public WG page
      wgURI:        "https://www.w3.org/community/json-ld/",

      // name (with the @w3c.org) of the public mailing to which comments are due
      wgPublicList: "public-linked-json",

      // URI of the patent status for this WG, for Rec-track documents
      // !!!! IMPORTANT !!!!
      // This is important for Rec-track documents, do not copy a patent URI from a random
      // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
      // Team Contact.
      //wgPatentURI:  "https://www.w3.org/2004/01/pp-impl/46168/status",
      maxTocLevel: 3
      ///alternateFormats: [ {uri: "diff-20140116.html", label: "diff to previous version"} ]
  };
//]]>
</script>
<style type="text/css">
  .hl-bold { font-weight: bold; color: #0a3; }
  .comment { color: #999; }
  table, thead, tr, td { padding: 5px; border-width: 1px; border-spacing: 0px; border-style: solid; border-collapse: collapse; }
  table.example {width: 100%;}
  .hl-bold {
    font-weight: bold;
    color: #0a3;
  }
  .comment {
    color: #999;
  }
  .changed {
    background-color: rgb(215, 238, 197);
  }
  .changed:hover {
    color:  green;
    background-color: inherit;
  }
</style>
</head>

<body>
<section id="abstract">
  <p>JSON is a useful data serialization and messaging format.
    This specification defines JSON-LD, a JSON-based format to serialize
    Linked Data. The syntax is designed to easily integrate into deployed
    systems that already use JSON, and provides a smooth upgrade path from
    JSON to JSON-LD.
    It is primarily intended to be a way to use Linked Data in Web-based
    programming environments, to build interoperable Web services, and to
    store Linked Data in JSON-based storage engines.</p>
</section>

<section id="sotd">
  <details class="annoying-warning" open="">
    <summary>Specification Moved</summary>
    <p>
      The Community Group completed work on this specification, the
      work is being continued by the <a href="https://www.w3.org/2018/json-ld-wg/">JSON-LD Working group</a>,
      see <a href="https://w3c.github.io/json-ld-syntax/">https://w3c.github.io/json-ld-syntax/</a> for the Editor's draft.      
    </p>
  </details>
  <p>This document has been developed by the
    <a href="https://www.w3.org/community/json-ld/">JSON for Linking Data W3C Community Group</a>
    as an update to the 1.0 recommendation [[JSON-LD]] developed
    by the <a href="https://www.w3.org/2011/rdf-wg/wiki/Main_Page">RDF Working Group</a>.
    The specification has undergone
    significant development, review, and changes during the course of several years.</p>

  <p>There are several independent
    <a href="https://json-ld.org/test-suite/reports/">interoperable implementations</a> of
    this specification, a test suite [[JSON-LD-TESTS]] and a
    <a href="https://json-ld.org/playground/">live JSON-LD playground</a> that is capable
    of demonstrating the features described in this document.</p>

  <section>
    <h2>Set of Documents</h2>
    <p>This document is one of three JSON-LD 1.1 Recommendations produced by the
      <a href="https://www.w3.org/community/json-ld/">JSON for Linking Data W3C Community Group</a>:</p>

    <ul>
      <li><a data-cite="JSON-LD11CG">JSON-LD 1.1</a></li>
      <li><a data-cite="JSON-LD11CG-API">JSON-LD 1.1 Processing Algorithms and API</a></li>
      <li><a data-cite="JSON-LD11CG-FRAMING">JSON-LD 1.1 Framing</a></li>
    </ul>
  </section>
</section>

<section class="informative">
  <h1>Introduction</h1>

  <p>Linked Data [[LINKED-DATA]] is a way to create a network of
   standards-based machine interpretable data across different documents and
   Web sites. It allows an application to start at one piece of Linked Data,
   and follow embedded links to other pieces of Linked Data that are hosted on
   different sites across the Web.</p>

  <p>JSON-LD is a lightweight syntax to serialize Linked Data in
    JSON [[!RFC7159]]. Its design allows existing JSON to be interpreted as
    Linked Data with minimal changes. JSON-LD is primarily intended to be a
    way to use Linked Data in Web-based programming environments, to build
    interoperable Web services, and to store Linked Data in JSON-based storage engines. Since
    JSON-LD is 100% compatible with JSON, the large number of JSON parsers and libraries
    available today can be reused. In addition to all the features JSON provides,
    JSON-LD introduces:</p>

  <ul>
    <li>a universal identifier mechanism for <a>JSON objects</a>
      via the use of <a>IRIs</a>,</li>
    <li>a way to disambiguate keys shared among different JSON documents by mapping
      them to <a>IRIs</a> via a <a>context</a>,</li>
    <li>a mechanism in which a value in a <a>JSON object</a> may refer
      to a <a>JSON object</a> on a different site on the Web,</li>
    <li>the ability to annotate <a>strings</a> with their language,</li>
    <li>a way to associate datatypes with values such as dates and times,</li>
    <li>and a facility to express one or more directed graphs, such as a social
      network, in a single document.</li>
  </ul>

  <p>
   JSON-LD is designed to be usable directly as JSON, with no knowledge of RDF
   [[RDF11-CONCEPTS]]. It is also designed to be usable as RDF, if desired, for
   use with other Linked Data technologies like SPARQL. Developers who
   require any of the facilities listed above or need to serialize an RDF Graph
   or <a>RDF Dataset</a> in a JSON-based syntax will find JSON-LD of interest. People
   intending to use JSON-LD with RDF tools will find it can be used as another
   RDF syntax, like Turtle [[TURTLE]]. Complete details of how JSON-LD relates
   to RDF are in section <a href="#relationship-to-rdf"></a>.
  </p>

  <p>
    The syntax is designed to not disturb already
   deployed systems running on JSON, but provide a smooth upgrade path from
   JSON to JSON-LD. Since the shape of such data varies wildly, JSON-LD
   features mechanisms to reshape documents into a deterministic structure
   which simplifies their processing.</p>

  <section class="informative">
    <h2>How to Read this Document</h2>

    <p>This document is a detailed specification for a serialization of Linked
      Data in JSON. The document is primarily intended for the following audiences:</p>

    <ul>
      <li>Software developers who want to encode Linked Data in a variety of
        programming languages that can use JSON</li>
      <li>Software developers who want to convert existing JSON to JSON-LD</li>
      <li>Software developers who want to understand the design decisions and
        language syntax for JSON-LD</li>
      <li>Software developers who want to implement processors and APIs for
        JSON-LD</li>
      <li>Software developers who want to generate or consume Linked Data,
        an RDF graph, or an <a>RDF Dataset</a> in a JSON syntax</li>
    </ul>

    <p>A companion document, the JSON-LD 1.1 Processing Algorithms and API specification
      [[JSON-LD11CG-API]], specifies how to work with JSON-LD at a higher level by
      providing a standard library interface for common JSON-LD operations.</p>

    <p>To understand the basics in this specification you must first be familiar with
      <a data-cite="RFC7159">JSON</a>, which is detailed in [[!RFC7159]].</p>

    <p>This document almost exclusively uses the term IRI
    (<a data-cite="ld-glossary#internationalized-resource-identifier">Internationalized Resource Indicator</a>)
    when discussing hyperlinks. Many Web developers are more familiar with the
    URL (<a data-cite="ld-glossary#uniform-resource-locator">Uniform Resource Locator</a>)
    terminology. The document also uses, albeit rarely, the URI
    (<a data-cite="ld-glossary#uniform-resource-identifier">Uniform Resource Indicator</a>)
    terminology. While these terms are often used interchangeably among
    technical communities, they do have important distinctions from one
    another and the specification goes to great lengths to try and use the
    proper terminology at all times.
    </p>
  </section>

  <section>
    <h2>Contributing</h2>

    <p>There are a number of ways that one may participate in the development of
      this specification:</p>

    <ul>
      <li>Technical discussion typically occurs on the public mailing list:
        <a href="https://lists.w3.org/Archives/Public/public-linked-json/">public-linked-json@w3.org</a></li>

      <!--<li><a href="https://json-ld.org/minutes/">Public teleconferences</a> are held
        on Tuesdays at 1500UTC on the second and fourth week of each month.</li> -->

      <li>The <a href="https://webchat.freenode.net/?channels=json-ld">#json-ld</a>
        IRC channel is available for real-time discussion on irc.freenode.net.</li>
    </ul>

  </section>

  <section class="normative">
    <h2>Terminology</h2>

    <p>This document uses the following terms as defined in JSON [[!RFC7159]]. Refer
      to the <a data-cite="RFC7159#section-2">JSON Grammar section</a> in [[!RFC7159]] for formal definitions.</p>

    <div data-include="../common/terms.html"
         data-oninclude="restrictReferences">
    </div>
  </section>

  <section>
    <h2>Typographical conventions</h2>
    <div data-include="../common/typographical-conventions.html"></div>
  </section>

  <section class="informative">
  <h2>Design Goals and Rationale</h2>

  <p>JSON-LD satisfies the following design goals:</p>

  <dl>
   <dt>Simplicity</dt>
   <dd>No extra processors or software libraries are necessary to use JSON-LD
     in its most basic form. The language provides developers with a very easy
     learning curve. Developers only need to know JSON and two
     <a>keywords</a> (<code>@context</code>
     and <code>@id</code>) to use the basic functionality in JSON-LD.</dd>
   <dt>Compatibility</dt>
   <dd>A JSON-LD document is always a valid JSON document. This ensures that
    all of the standard JSON libraries work seamlessly with JSON-LD documents.</dd>
   <dt>Expressiveness</dt>
   <dd>The syntax serializes directed graphs. This ensures that almost
    every real world data model can be expressed.</dd>
   <dt>Terseness</dt>
   <dd>The JSON-LD syntax is very terse and human readable, requiring as
    little effort as possible from the developer.</dd>
   <dt>Zero Edits, most of the time</dt>
   <dd>JSON-LD ensures a smooth and simple transition from existing
     JSON-based systems. In many cases,
     zero edits to the JSON document and the addition of one line to the HTTP response
     should suffice (see <a class="sectionRef" href="#interpreting-json-as-json-ld"></a>).
     This allows organizations that have
     already deployed large JSON-based infrastructure to use JSON-LD's features
     in a way that is not disruptive to their day-to-day operations and is
     transparent to their current customers. However, there are times where
     mapping JSON to a graph representation is a complex undertaking.
     In these instances, rather than extending JSON-LD to support
     esoteric use cases, we chose not to support the use case. While Zero
     Edits is a design goal, it is not always possible without adding
     great complexity to the language. JSON-LD focuses on simplicity when
     possible.</dd>
    <dt>Usable as RDF</dt>
    <dd>JSON-LD is usable by developers as
      idiomatic JSON, with no need to understand RDF [[RDF11-CONCEPTS]].
      JSON-LD is also usable as RDF, so people intending to use JSON-LD
      with RDF tools will find it can be used like any other RDF syntax.
      Complete details of how JSON-LD relates to RDF are in section
      <a href="#relationship-to-rdf"></a>.</dd>
  </dl>
</section>

  <section class="informative">
    <h2>Data Model Overview</h2>

    <p>Generally speaking, the data model described by a
      <a>JSON-LD document</a> is a labeled,
      directed <a>graph</a>. The graph contains
      <a>nodes</a>, which are connected by
      <a>edges</a>. A <a>node</a> is typically data
      such as a <a>string</a>, <a>number</a>,
      <a>typed values</a> (like dates and times)
      or an <a>IRI</a>.
      There is also a special class of <a>node</a> called a
      <a>blank node</a>, which is typically used to express data that does
      not have a global identifier like an <a>IRI</a>.
      <a>Blank nodes</a> are identified using a
      <a>blank node identifier</a>. This simple data model is incredibly
      flexible and powerful, capable of modeling almost any kind of
      data. For a deeper explanation of the data model, see
      section <a href="#data-model"></a>.
    </p>

    <p>Developers who are familiar with Linked Data technologies will
      recognize the data model as the RDF Data Model. To dive deeper into how
      JSON-LD and RDF are related, see
      section <a href="#relationship-to-rdf"></a>.</p>

    <p>At the surface level, a <a>JSON-LD document</a> is simply
      <a data-cite="RFC7159">JSON</a>, detailed in [[!RFC7159]].
      For the purpose of describing the core data structures,
      this is limited to <a>arrays</a>, <a>dictionaries</a> (the parsed version of a <a>JSON Object</a>),
      <a>strings</a>, <a>numbers</a>, <a>booleans</a>, and <a>null</a>,
      <span class="changed">called the <a>JSON-LD internal representation</a>.
        This allows surface syntaxes other than JSON
        to be manipulated using the same algorithms, when the syntax maps
        to equivalent core data structures</span>.</p>
      <p class="changed note">Although not discussed in this specification,
        parallel work using <a data-cite="YAML">YAML</a> [[YAML]]
        and binary representations such as <a data-cite="RFC7049">CBOR</a> [[RFC7049]]
        could be used to map into the <a>internal representation</a>, allowing
        the JSON-LD 1.1 API [[JSON-LD11CG-API]] to operate as if the source was a
        JSON document.</p>
  </section>

  <section class="normative">
    <h2>Syntax Tokens and Keywords</h2>

    <p>JSON-LD specifies a number of syntax tokens and <a>keywords</a>
    that are a core part of the language:</p>

    <dl data-sort>
      <dt><code>@context</code></dt>
      <dd>Used to define the short-hand names that are used throughout a JSON-LD
        document. These short-hand names are called <a>terms</a> and help
        developers to express specific identifiers in a compact manner. The
        <code>@context</code> keyword is described in detail in
        <a class="sectionRef" href="#the-context"></a>.</dd>
      <dt><code>@id</code></dt>
      <dd>Used to uniquely identify <em>things</em> that are being described in the document
        with <a>IRIs</a> or
        <a>blank node identifiers</a>. This keyword
        is described in <a class="sectionRef" href="#node-identifiers"></a>.</dd>
      <dt><code>@value</code></dt>
      <dd>Used to specify the data that is associated with a particular
        <a>property</a> in the graph. This keyword is described in
        <a class="sectionRef" href="#string-internationalization"></a> and
        <a class="sectionRef" href="#typed-values"></a>.</dd>
      <dt><code>@language</code></dt>
      <dd>Used to specify the language for a particular string value or the default
        language of a JSON-LD document. This keyword is described in
        <a class="sectionRef" href="#string-internationalization"></a>.</dd>
      <dt><code>@type</code></dt>
      <dd>Used to set the data type of a <a>node</a> or
        <a>typed value</a>. This keyword is described in
        <a class="sectionRef" href="#typed-values"></a>.</dd>
      <dt><code>@container</code></dt>
      <dd>Used to set the default container type for a <a>term</a>.
        This keyword is described in the following sections:
        <ul>
        <li><a class="sectionRef" href="#sets-and-lists"></a>,</li>
        <li class="changed"><a class="sectionRef" href="#named-graphs"></a>,</li>
        <li><a class="sectionRef" href="#data-indexing"></a>,</li>
        <li class="changed"><a class="sectionRef" href="#named-graph-indexing"></a>,</li>
        <li class="changed"><a class="sectionRef" href="#language-indexing"></a>,</li>
        <li class="changed"><a class="sectionRef" href="#node-identifier-indexing"></a>,</li>
        <li class="changed"><a class="sectionRef" href="#named-graph-indexing-by-identifier"></a>, and</li>
        <li class="changed"><a class="sectionRef" href="#node-type-indexing"></a>.</li>
        </ul></dd>
      <dt><code>@list</code></dt>
      <dd>Used to express an ordered set of data.
        This keyword is described in <a class="sectionRef" href="#sets-and-lists"></a>.</dd>
      <dt><code>@set</code></dt>
      <dd>Used to express an unordered set of data and to ensure that values are always
         represented as arrays. This keyword is described in
         <a class="sectionRef" href="#sets-and-lists"></a>.</dd>
      <dt><code>@reverse</code></dt>
      <dd>Used to express reverse properties. This keyword is described in
        <a class="sectionRef" href="#reverse-properties"></a>.</dd>
      <dt><code>@index</code></dt>
      <dd>Used to specify that a container is used to index information and
        that processing should continue deeper into a JSON data structure.
        This keyword is described in <a class="sectionRef" href="#data-indexing"></a>.</dd>
      <dt><code>@base</code></dt>
      <dd>Used to set the <a>base IRI</a> against which to resolve those <a>relative IRIs</a>
        interpreted relative to the document.
        This keyword is described in <a class="sectionRef" href="#base-iri"></a>.</dd>
      <dt><code>@vocab</code></dt>
      <dd>Used to expand properties and values in <code>@type</code> with a common prefix
        <a>IRI</a>. This keyword is described in <a class="sectionRef" href="#default-vocabulary"></a>.</dd>
      <dt><code>@graph</code></dt><dd>Used to express a <a>graph</a>.
        This keyword is described in <a class="sectionRef" href="#named-graphs"></a>.</dd>
      <dt class="changed"><code>@nest</code></dt><dd class="changed">Collects a set of <a>nested properties</a> within
        a <a>node object</a>.</dd>
      <dt class="changed"><code>@none</code></dt><dd class="changed">Used as an index value
        in an id map, language map, type map or elsewhere where a dictionary is
        used to index into other values.</dd>
      <dt class="changed"><code>@prefix</code></dt><dd class="changed">
        With the value <a>true</a>, allows this <a>term</a> to be used to construct a <a>compact IRI</a>
        when compacting.</dd>
      <dt class="changed"><code>@version</code></dt><dd class="changed">
        Used in a <a>context definition</a> to set the <a>processing mode</a>.
        New features since <a data-cite="JSON-LD">JSON-LD 1.0</a> [[!JSON-LD]] described in this specification are
        only available when <a>processing mode</a> has been explicitly set to
        <code>json-ld-1.1</code>.
      </dd>
      <dt><code>:</code></dt>
      <dd>The separator for JSON keys and values that use
        <a>compact IRIs</a>.</dd>
    </dl>

    <p>All keys, <a>keywords</a>, and values in JSON-LD are case-sensitive.</p>
  </section>
</section>

<section id="conformance">
  <p>Conformance criteria are relevant to authors and authoring tool implementers. As well
    as sections marked as non-normative, all authoring guidelines, diagrams, examples,
    and notes in this specification are non-normative. Everything else in this
    specification is normative.</p>

  <p>A <a>JSON-LD document</a> complies with this specification if it follows
    the normative statements in appendix <a href="#json-ld-grammar"></a>. JSON documents
    can be interpreted as JSON-LD by following the normative statements in
    <a class="sectionRef" href="#interpreting-json-as-json-ld"></a>. For convenience, normative
    statements for documents are often phrased as statements on the properties of the document.</p>

  <p>This specification makes use of the following namespaces:</p>
  <dl>
    <dt><code>dc</code>:</dt>
    <dd><code>http://purl.org/dc/terms/</code></dd>
    <dt><code>cred</code>:</dt>
    <dd><code>https://w3id.org/credentials#</code></dd>
    <dt><code>foaf</code>:</dt>
    <dd><code>http://xmlns.com/foaf/0.1/</code></dd>
    <dt><code>prov</code></dt>
    <dd><code>http://www.w3.org/ns/prov#</code></dd>
    <dt><code>rdf</code>:</dt>
    <dd><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code></dd>
    <dt><code>schema</code>:</dt>
    <dd><code>http://schema.org/</code></dd>
    <dt><code>xsd</code>:</dt>
    <dd><code>http://www.w3.org/2001/XMLSchema#</code></dd>
  </dl>
</section>

<section class="informative">
  <h1>Basic Concepts</h1>

  <p>JSON [[RFC7159]] is a lightweight, language-independent data interchange format.
    It is easy to parse and easy to generate. However, it is difficult to integrate JSON
    from different sources as the data may contain keys that conflict with other
    data sources. Furthermore, JSON has no
    built-in support for hyperlinks, which are a fundamental building block on
    the Web. Let's start by looking at an example that we will be using for the
    rest of this section:</p>

  <pre class="example" data-transform="updateExample"
       title="Sample JSON document">
  <!--
  {
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    "image": "http://manu.sporny.org/images/manu.png"
  }
  -->
  </pre>

  <p>It's obvious to humans that the data is about a person whose
    <code>name</code> is "Manu Sporny"
    and that the <code>homepage</code> property contains the URL of that person's homepage.
    A machine doesn't have such an intuitive understanding and sometimes,
    even for humans, it is difficult to resolve ambiguities in such representations. This problem
    can be solved by using unambiguous identifiers to denote the different concepts instead of
    tokens such as "name", "homepage", etc.</p>

  <p>Linked Data, and the Web in general, uses <a>IRIs</a>
    (<a data-cite="RFC3987#section-2">Internationalized Resource Identifiers</a> as described in [[!RFC3987]]) for unambiguous
    identification. The idea is to use <a>IRIs</a>
    to assign unambiguous identifiers to data that may be of use to other developers.
    It is useful for <a>terms</a>,
    like <code>name</code> and <code>homepage</code>, to expand to <a>IRIs</a>
    so that developers don't accidentally step on each other's terms. Furthermore, developers and
    machines are able to use this <a>IRI</a> (by using a web browser, for instance) to go to
    the term and get a definition of what the term means. This process is known as <a>IRI</a>
    dereferencing.</p>

  <p>Leveraging the popular <a href="http://schema.org/">schema.org vocabulary</a>,
    the example above could be unambiguously expressed as follows:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Sample JSON-LD document using full IRIs instead of terms">
  <!--
  {
    "****http://schema.org/name****": "Manu Sporny",
    "****http://schema.org/url****": ****{ "@id": ****"http://manu.sporny.org/" ****}****,  ####← The '@id' keyword means 'This value is an identifier that is an IRI'####
    "****http://schema.org/image****": ****{ "@id": ****"http://manu.sporny.org/images/manu.png" ****}****
  }
  -->
  </pre>

  <p>In the example above, every property is unambiguously identified by an <a>IRI</a> and all values
    representing <a>IRIs</a> are explicitly marked as such by the
    <code>@id</code> <a>keyword</a>. While this is a valid JSON-LD
    document that is very specific about its data, the document is also overly verbose and difficult
    to work with for human developers. To address this issue, JSON-LD introduces the notion
    of a <a>context</a> as described in the next section.</p>

  <section class="informative">
    <h2>The Context</h2>

    <p>When two people communicate with one another, the conversation takes
    place in a shared environment, typically called
    "the context of the conversation". This shared context allows the
    individuals to use shortcut terms, like the first name of a mutual friend,
    to communicate more quickly but without losing accuracy. A context in
    JSON-LD works in the same way. It allows two applications to use shortcut
    terms to communicate with one another more efficiently, but without
    losing accuracy.</p>

    <p>Simply speaking, a <a>context</a> is used to map <a>terms</a> to
      <a>IRIs</a>. <a>Terms</a> are case sensitive
      and any valid <a>string</a> that is not a reserved JSON-LD <a>keyword</a>
      can be used as a <a>term</a>.</p>

    <p>For the sample document in the previous section, a <a>context</a> would
      look something like this:</p>

    <pre class="example nohighlight" data-transform="updateExample"
         title="Context for the sample document in the previous section">
    <!--
    {
      ****"@context": {
        "name": "http://schema.org/name",****  ####← This means that 'name' is shorthand for 'http://schema.org/name'#### ****
        "image": {
          "@id": "http://schema.org/image",****  ####← This means that 'image' is shorthand for 'http://schema.org/image'#### ****
          "@type": "@id"****  ####← This means that a string value associated with 'image' should be interpreted as an identifier that is an IRI#### ****
        },
        "homepage": {
          "@id": "http://schema.org/url",****  ####← This means that 'homepage' is shorthand for 'http://schema.org/url'#### ****
          "@type": "@id"****  ####← This means that a string value associated with 'homepage' should be interpreted as an identifier that is an IRI#### ****
        }
      }****
    }
    -->
    </pre>

    <p>As the <a>context</a> above shows, the value of a <a>term definition</a> can
      either be a simple string, mapping the <a>term</a> to an <a>IRI</a>,
      or a <a>JSON object</a>.</p>

    <p>When a <a>JSON object</a> is associated with a term, it is called
      an <a>expanded term definition</a>. The example above specifies that
      the values of <code>image</code> and <code>homepage</code>, if they are
      strings, are to be interpreted as
      <a>IRIs</a>. <a>Expanded term definitions</a>
      also allow terms to be used for <a href="#data-indexing">index maps</a>
      and to specify whether <a>array</a> values are to be
      interpreted as <a href="#sets-and-lists">sets or lists</a>.
      <a>Expanded term definitions</a> may
      be defined using <a data-lt="absolute IRI">absolute</a> or
      <a>compact IRIs</a> as keys, which is
      mainly used to associate type or language information with an
      <a data-lt="absolute IRI">absolute</a> or <a>compact IRI</a>.</p>

    <p><a>Contexts</a> can either be directly embedded
      into the document or be referenced. Assuming the context document in the previous
      example can be retrieved at <code>https://json-ld.org/contexts/person.jsonld</code>,
      it can be referenced by adding a single line and allows a JSON-LD document to
      be expressed much more concisely as shown in the example below:</p>

    <pre class="example nohighlight" data-transform="updateExample"
         title="Referencing a JSON-LD context">
    <!--
    {
      ****"@context": "https://json-ld.org/contexts/person.jsonld",****
      "name": "Manu Sporny",
      "homepage": "http://manu.sporny.org/",
      "image": "http://manu.sporny.org/images/manu.png"
    }
    -->
    </pre>

    <p>The referenced context not only specifies how the terms map to
      <a>IRIs</a> in the Schema.org vocabulary but also
      specifies that string values associated with
      the <code>homepage</code> and <code>image</code> property
      can be interpreted as an <a>IRI</a> (<code>"@type": "@id"</code>,
      see <a class="sectionRef" href="#iris"></a> for more details). This information allows developers
      to re-use each other's data without having to agree to how their data will interoperate
      on a site-by-site basis. External JSON-LD context documents may contain extra
      information located outside of the <code>@context</code> key, such as
      documentation about the <a>terms</a> declared in the
      document. Information contained outside of the <code>@context</code> value
      is ignored when the document is used as an external JSON-LD context document.</p>

    <p>JSON documents can be interpreted as JSON-LD without having to be modified by
      referencing a <a>context</a> via an <a data-cite="RFC5988#section-5">HTTP Link Header</a>
      as described in <a class="sectionRef" href="#interpreting-json-as-json-ld"></a>. It is also
      possible to apply a custom context using the JSON-LD 1.1 API [[JSON-LD11CG-API]].</p>

    <p>In <a>JSON-LD documents</a>,
      <a>contexts</a> may also be specified inline.
      This has the advantage that documents can be processed even in the
      absence of a connection to the Web. Ultimately, this is a modeling decision
      and different use cases may require different handling.</p>

    <pre class="example nohighlight" data-transform="updateExample"
         title="In-line context definition">
    <!--
    {
      ****"@context": {
        "name": "http://schema.org/name",
        "image": {
          "@id": "http://schema.org/image",
          "@type": "@id"
        },
        "homepage": {
          "@id": "http://schema.org/url",
          "@type": "@id"
        }
      },****
      "name": "Manu Sporny",
      "homepage": "http://manu.sporny.org/",
      "image": "http://manu.sporny.org/images/manu.png"
    }
    -->
    </pre>

    <p>This section only covers the most basic features of the JSON-LD
    Context. More advanced features related to the JSON-LD Context are covered
    in section <a href="#advanced-concepts" class="sectionRef"></a>.
    </p>
  </section>

<section class="informative">
  <h2>IRIs</h2>

  <p><a>IRIs</a> (<a data-cite="RFC3987#section-2">Internationalized Resource Identifiers</a>
    [[!RFC3987]]) are fundamental to Linked Data as that is how most
    <a>nodes</a> and <a>properties</a>
    are identified. In JSON-LD, IRIs may be represented as an
    <a>absolute IRI</a> or a <a>relative IRI</a>. An
    <a data-cite="RFC3987#section-1.3">absolute IRI</a> is defined in [[!RFC3987]] as containing a
    <em>scheme</em> along with <em>path</em> and optional <em>query</em> and
    <em>fragment</em> segments. A <a>relative IRI</a> is an IRI
    that is relative to some other <a>absolute IRI</a>.
    In JSON-LD, with exceptions are as described below, all <a>relative IRIs</a>
    are resolved relative to the <a>base IRI</a>.</p>

  <p class="note"><a>Properties</a>, values of <code>@type</code>,
    and values of <a>properties</a> with a <a>term definition</a>
    that defines them as being relative to the <a>vocabulary mapping</a>,
    may have the form of a <a>relative IRI</a>, but are resolved using the
    <a>vocabulary mapping</a>, and not the <a>base IRI</a>.</p>

  <p>A <a>string</a> is interpreted as an <a>IRI</a> when it is the
    value of an <code>@id</code> member:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Values of @id are interpreted as IRI">
  <!--
  {
    ####...####
    "homepage": { "****@id****": "http://example.com/" }
    ####...####
  }
  -->
  </pre>

  <p>Values that are interpreted as <a>IRIs</a>, can also be
    expressed as <a>relative IRIs</a>. For example,
    assuming that the following document is located at
    <code>http://example.com/about/</code>, the <a>relative IRI</a>
    <code>../</code> would expand to <code>http://example.com/</code> (for more
    information on where  <a>relative IRIs</a> can be
    used, please refer to section <a href="#json-ld-grammar"></a>).</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="IRIs can be relative">
  <!--
  {
    ####...####
    "homepage": { "****@id****": "../" }
    ####...####
  }
  -->
  </pre>

  <p><a>Absolute IRIs</a> can be expressed directly
    in the key position like so:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="IRI as a key">
  <!--
  {
    ####...####
    "****http://schema.org/name****": "Manu Sporny"####,
    ...####
  }
  -->
  </pre>

  <p>In the example above, the key <code>http://schema.org/name</code>
    is interpreted as an <a>absolute IRI</a>.</p>

  <p>Term-to-IRI expansion occurs if the key matches a <a>term</a> defined
    within the <a>active context</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Term expansion from context definition">
  <!--
  {
    "****@context****": {
      "****name****": "****http://schema.org/name****"
    },
    "****name****": "Manu Sporny",
    "status": "trollin'"
  }
  -->
  </pre>

  <p>JSON keys that do not expand to an <a>IRI</a>, such as <code>status</code>
    in the example above, are not Linked Data and thus ignored when processed.</p>

  <p>If type <a>coercion</a> rules are specified in the <code>@context</code> for
    a particular <a>term</a> or property IRI, an IRI is generated:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Type coercion">
  <!--
  {****
    "@context": {
      ####...####
      "homepage": {
        "@id": "http://schema.org/url",
        "@type": "@id"
      }
      ####...####
    },****
    ####...####
    "homepage": "http://manu.sporny.org/"
    ####...####
  }
  -->
  </pre>

  <p>In the example above, since the value <code>http://manu.sporny.org/</code>
    is expressed as a JSON <a>string</a>, the type <a>coercion</a>
    rules will transform the value into an IRI when processing the data.
    See <a class="sectionRef" href="#type-coercion"></a> for more
    details about this feature.</p>

  <p>In summary, <a>IRIs</a> can be expressed in a variety of
    different ways in JSON-LD:</p>

  <ol>
    <li><a>JSON object</a> keys that have a <a>term</a> mapping in
      the <a>active context</a> expand to an <a>IRI</a>
      (only applies outside of the <a>context definition</a>).</li>
    <li>An <a>IRI</a> is generated for the <a>string</a> value specified using
      <code>@id</code> or <code>@type</code>.</li>
    <li>An <a>IRI</a> is generated for the <a>string</a> value of any key for which there
      are <a>coercion</a> rules that contain an <code>@type</code> key that is
      set to a value of <code>@id</code> or <code>@vocab</code>.</li>
  </ol>

  <p>This section only covers the most basic features associated with IRIs
  in JSON-LD. More advanced features related to IRIs are covered in
  section <a href="#advanced-concepts"></a>.
  </p>

</section>

<section class="informative">
  <h2>Node Identifiers</h2>

  <p>To be able to externally reference <a>nodes</a>
    in a <a>graph</a>, it is important that
    <a>nodes</a> have an identifier. <a>IRIs</a>
    are a fundamental concept of Linked Data, for
    <a>nodes</a> to be truly linked, dereferencing the
    identifier should result in a representation of that <a>node</a>.
    This may allow an application to retrieve further information about a
    <a>node</a>.</p>

  <p>In JSON-LD, a <a>node</a> is identified using the <code>@id</code>
    <a>keyword</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Identifying a node">
  <!--
  {
    "@context": {
      ####...####
      "name": "http://schema.org/name"
    },
    ****"@id": "http://me.markus-lanthaler.com/"****,
    "name": "Markus Lanthaler"####,
    ...####
  }
  -->
  </pre>

  <p>The example above contains a <a>node object</a> identified by the IRI
    <code>http://me.markus-lanthaler.com/</code>.</p>

  <p>This section only covers the most basic features associated with
  node identifiers in JSON-LD. More advanced features related to
  node identifiers are covered in section <a href="#advanced-concepts"></a>.
  </p>

</section>

<section class="informative">
<h2>Specifying the Type</h2>

<p>The type of a particular node can be specified using the <code>@type</code>
  <a>keyword</a>. In Linked Data, types are uniquely
  identified with an <a>IRI</a>.</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Specifying the type for a node">
<!--
{
  ####...####
  "@id": "http://example.org/places#BrewEats",
  "****@type****": "****http://schema.org/Restaurant****"####,
  ...####
}
-->
</pre>

<p>A node can be assigned more than one type by using an <a>array</a>:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Specifying multiple types for a node">
<!--
{
  ####...####
  "@id": "http://example.org/places#BrewEats",
  "****@type****": ****[ "http://schema.org/Restaurant", "http://schema.org/Brewery" ]****####,
  ...####
}
-->
</pre>

<p>The value of an <code>@type</code> key may also be a <a>term</a> defined in the <a>active context</a>:</p>
<pre class="example nohighlight" data-transform="updateExample"
     title="Using a term to specify the type">
<!--
{
  "@context": {
    ####...####
    ****"Restaurant": "http://schema.org/Restaurant", ****
    ****"Brewery": "http://schema.org/Brewery"****
  },
  "@id": "http://example.org/places#BrewEats",
  ****"@type": [ "Restaurant", "Brewery" ]****####,
  ...####
}
-->
</pre>

<p class="note">This section only covers the most basic features associated with
  types in JSON-LD. It is worth noting that the <code>@type</code>
  <a>keyword</a> is not only used to specify the type of a
  <a>node</a> but also to express <a>typed values</a>
  (as described in <a class="sectionRef" href="#typed-values"></a>) and to
  <a data-lt="coercion">type coerce</a> values (as described in
  <a class="sectionRef" href="#type-coercion"></a>). Specifically, <code>@type</code>
  cannot be used in a <a>context</a> to define a <a>node</a>'s
  type. For a detailed description of the differences, please refer to
  <a class="sectionRef" href="#typed-values"></a>.</p>

</section>
</section>

<section class="normative">
<h1>Advanced Concepts</h1>

<p>JSON-LD has a number of features that provide functionality above and beyond
  the core functionality described above. The following section describes this
  advanced functionality in more detail.</p>

<section class="changed informative">
  <h2>JSON-LD 1.1 Processing Mode</h2>

  <p>New features defined in JSON-LD 1.1 are available
    when the <a>processing mode</a> is set to <code>json-ld-1.1</code>.
    This may be set using the <code>@version</code> member in a <code>context</code>
    set to the value <code>1.1</code> as a <a>number</a>, or through an API option.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Setting @version in context">
  <!--
  {
    "@context": {
      ****"@version": 1.1****####,
      ...####
    }####,
    ...####
  }
  -->
  </pre>

  <p>The first <code>context</code> encountered when processing a
    document which contains <code>@version</code> determines the <code>processing mode</code>,
    unless it is defined explicitly through an API option.</p>

  <p class="note">Setting the <a>processing mode</a> explicitly
    for JSON-LD 1.1 is necessary so that a JSON-LD 1.0 processor
    does not attempt to process a JSON-LD 1.1 document and silently
    produce different results.</p>
</section>

<section class="informative">
  <h2>Base IRI</h2>

  <p>JSON-LD allows <a>IRIs</a>
    to be specified in a relative form which is
    resolved against the document base according
    <a data-cite="RFC3986#section-5.1">section 5.1 Establishing a Base URI</a>
    of [[RFC3986]]. The <a>base IRI</a> may be explicitly set with a <a>context</a>
    using the <code>@base</code> keyword.</p>

  <p>For example, if a JSON-LD document was retrieved from <code>http://example.com/document.jsonld</code>,
    relative IRIs would resolve against that IRI:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Use a relative IRI as node identifier">
    <!--
    {
      "@context": {
        "label": "http://www.w3.org/2000/01/rdf-schema#label"
      },
      ****"@id": ""****,
      "label": "Just a simple document"
    }
    -->
  </pre>

  <p>This document uses an empty <code>@id</code>, which resolves to the document base.
    However, if the document is moved to a different location, the <a>IRI</a> would change.
    To prevent this without having to use an <a>absolute IRI</a>, a <a>context</a>
    may define an <code>@base</code> mapping, to overwrite the <a>base IRI</a> for the document.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Setting the document base in a document">
  <!--
  {
    "@context": {
      ****"@base": "http://example.com/document.jsonld",****
      "label": "http://www.w3.org/2000/01/rdf-schema#label"
    },
    "@id": "",
    "label": "Just a simple document"
  }
  -->
  </pre>

  <p>Setting <code>@base</code> to <a>null</a> will prevent
    <a>relative IRIs</a> to be expanded to
    <a>absolute IRIs</a>.</p>

  <p>Please note that the <code>@base</code> will be ignored if used in
    external contexts.</p>
</section>

<section class="informative">
  <h2>Default Vocabulary</h2>

  <p>At times, all properties and types may come from the same vocabulary. JSON-LD's
    <code>@vocab</code> keyword allows an author to set a common prefix which
    is used as the <a>vocabulary mapping</a> and is used
    for all properties and types that do not match a <a>term</a> and are neither
    a <a>compact IRI</a> nor an <a>absolute IRI</a> (i.e., they do
    not contain a colon).</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Using a common vocabulary prefix">
  <!--
    {
      "@context": {
        ****"@vocab": "http://schema.org/"****
      },
      "@id": "http://example.org/places#BrewEats",
      "@type": ****"Restaurant"****,
      ****"name"****: "Brew Eats"
      ####...####
    }
  -->
  </pre>

  <p>If <code>@vocab</code> is used but certain keys in an
    <a data-lt="JSON object">object</a> should not be expanded using
    the vocabulary <a>IRI</a>, a <a>term</a> can be explicitly set
    to <a>null</a> in the <a>context</a>. For instance, in the
    example below the <code>databaseId</code> member would not expand to an
    <a>IRI</a> causing the property to be dropped when expanding.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Using the null keyword to ignore data">
  <!--
    {
      "@context": {
         "@vocab": "http://schema.org/",
         ****"databaseId": null****
      },
      "@id": "http://example.org/places#BrewEats",
      "@type": "Restaurant",
      "name": "Brew Eats",
      ****"databaseId"****: "23987520"
    }
  -->
  </pre>

  <section class="changed">
    <h3>Using the Document Base as the Default Vocabulary</h3>
    <p>In some cases, vocabulary terms are defined directly within the document
      itself, rather than in an external vocabulary. Since
      <code>json-ld-1.1</code>, the <a>vocabulary mapping</a> in the <a>active
      context</a> can be set to the empty string <code>&quot;&quot;</code>, which causes terms which
      are expanded relative to the vocabulary, such as the keys of <a>node
      objects</a>, to use the <a>base IRI</a> to create <a>absolute
      IRIs</a>.</p>
  <pre class="example nohighlight" data-transform="updateExample"
       title="Using &quot;&quot; as the vocabulary mapping"
       data-base="http://example/document">
  <!--
    {
      "@context": {
        ****"@version": 1.1,****
        ****"@base": "http://example/document",****
        "@vocab": ****""****
      },
      "@id": "http://example.org/places#BrewEats",
      "@type": ****"#Restaurant"****,
      ****"#name"****: "Brew Eats"
      ####...####
    }
  -->
  </pre>
  <p>If this document were located at <code>http://example/document</code>, it would expand as follows:</p>
  <pre class="example nohighlight" data-transform="updateExample"
       title="Using &quot;&quot; as the vocabulary mapping (expanded)">
  <!--
    [{
      "@id": "http://example.org/places#BrewEats",
      "@type": ["http://example/document#Restaurant"],
      "http://example/document#name": [{"@value": "Brew Eats"}]
    }]
  -->
  </pre>
  </section>
</section>

<section class="informative">
  <h2>Compact IRIs</h2>

  <p>A <a>compact IRI</a> is a way of expressing an <a>IRI</a>
    using a <em>prefix</em> and <em>suffix</em> separated by a colon (<code>:</code>).
    The <a>prefix</a> is a <a>term</a> taken from the
    <a>active context</a> and is a short string identifying a
    particular <a>IRI</a> in a JSON-LD document. For example, the
    prefix <code>foaf</code> may be used as a short hand for the
    Friend-of-a-Friend vocabulary, which is identified using the <a>IRI</a>
    <code>http://xmlns.com/foaf/0.1/</code>. A developer may append
    any of the FOAF vocabulary terms to the end of the prefix to specify a short-hand
    version of the <a>absolute IRI</a> for the vocabulary term. For example,
    <code>foaf:name</code> would be expanded to the IRI
    <code>http://xmlns.com/foaf/0.1/name</code>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Prefix expansion">
  <!--
  {
    "****@context****": {
      "****foaf****": "****http://xmlns.com/foaf/0.1/****"
      ####...####
    },
    "@type": "****foaf:Person****",
    "****foaf:name****": "Dave Longley"####,
    ...####
  }
  -->
  </pre>

  <p>In the example above, <code>foaf:name</code> expands to the <a>IRI</a>
    <code>http://xmlns.com/foaf/0.1/name</code> and <code>foaf:Person</code> expands
    to <code>http://xmlns.com/foaf/0.1/Person</code>.</p>

  <p><a>Prefixes</a> are expanded when the form of the value
    is a <a>compact IRI</a> represented as a <code>prefix:suffix</code>
    combination, the <em>prefix</em> matches a <a>term</a> defined within the
    <a>active context</a>, and the <em>suffix</em> does not begin with two
    slashes&nbsp;(<code>//</code>). The <a>compact IRI</a> is expanded by
    concatenating the <a>IRI</a> mapped to the <em>prefix</em> to the (possibly empty)
    <em>suffix</em>. If the <em>prefix</em> is not defined in the <a>active context</a>,
    or the suffix begins with two slashes (such as in <code>http://example.com</code>),
    the value is interpreted as <a>absolute IRI</a> instead. If the prefix is an
    underscore (<code>_</code>), the value is interpreted as <a>blank node identifier</a>
    instead.</p>

  <p>It's also possible to use compact IRIs within the context as shown in the
    following example:</p>

  <pre class="example nohighlight" data-transform="updateExample"
     title="Using vocabularies">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      ****"foaf": "http://xmlns.com/foaf/0.1/"****,
      ****"foaf:homepage"****: { "@type": "@id" },
      "picture": { "@id": ****"foaf:depiction"****, "@type": "@id" }
    },
    "@id": "http://me.markus-lanthaler.com/",
    "@type": "foaf:Person",
    "foaf:name": "Markus Lanthaler",
    "foaf:homepage": "http://www.markus-lanthaler.com/",
    "picture": "http://twitter.com/account/profile_image/markuslanthaler"
  }
  -->
  </pre>

  <p class="changed">In JSON-LD 1.0, terms may be chosen as <a>compact IRI</a> prefixes when
    compacting only if a <a>simple term definition</a> is used where the value ends with a
    URI <a data-cite="RFC3986#section-2.2">gen-delim</a> character (e.g, <code>/</code>,
    <code>#</code> and others, see [[!RFC3986]]).
    <span class="note">The previous specification allows any term to be chosen as
      a compact IRI prefix, which led to a poor experience.</span></p>

  <p class="changed">In JSON-LD 1.1, terms may be chosen as <a>compact IRI</a> prefixes
    when compacting only if
    a <a>simple term definition</a> is used where the value ends with a URI <a data-cite="RFC3986#section-2.2">gen-delim</a> character,
    or if their <a>expanded term definition</a> contains
    a <code>@prefix</code> member with the value <a>true</a>.</p>

  <p class="note">This represents a small change to the 1.0 algorithm to prevent IRIs
    that are not really intended to be used as prefixes from being used for creating
    <a>compact IRIs</a>.</p>

  <p class="changed">When <a>processing mode</a> is set to <code>json-ld-1.1</code>, terms will be used as <a>compact IRI</a> prefixes
    when compacting only if their <a>expanded term definition</a> contains
    a <code>@prefix</code> member with the value <a>true</a>, or if it has a
    a <a>simple term definition</a>  where the value ends with a URI <a data-cite="RFC3986#section-2.2">gen-delim</a> character
    (e.g, <code>/</code>, <code>#</code> and others, see [[!RFC3986]]).</p>

  <pre class="example nohighlight changed" data-transform="updateExample"
     title="Using explicit @prefix declaration to create compact IRIs">
  <!--
  {
    "@context": {
      "compact-iris": {"@id": "http://example.com/compact-iris-", ****"@prefix": true****},
      "property": "http://example.com/property"
    },
    "property": {
      "@id": ****"compact-iris:are-considered"****,
      "property": "@prefix does not require a gen-delim"
    }
  }
  -->
  </pre>

  <p class="changed">In this case, the <em>compact-iris</em> term would not normally be usable as a prefix, both
    because it is defined with an <a>expanded term definition</a>, and because
    it's <code>@id</code> does not end in a
    <a data-cite="RFC3986#section-2.2">gen-delim</a> character. Adding
    <code>"@prefix": true</code> allows it to be used as the prefix portion of
    the <a>compact IRI</a> <em>compact-iris:are-considered</em>.</p>
</section>

<section class="informative">
<h2>Typed Values</h2>

<p>
  A value with an associated type, also known as a
  <a>typed value</a>, is indicated by associating a value with
  an <a>IRI</a> which indicates the value's type. Typed values may be
  expressed in JSON-LD in three ways:
</p>

<ol>
  <li>By utilizing the <code>@type</code> <a>keyword</a> when defining
    a <a>term</a> within an <code>@context</code> section.</li>
  <li>By utilizing a <a>value object</a>.</li>
  <li>By using a native JSON type such as <a>number</a>, <a>true</a>, or <a>false</a>.</li>
</ol>

<p>The first example uses the <code>@type</code> keyword to associate a
type with a particular <a>term</a> in the <code>@context</code>:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Expanded term definition with type coercion">
<!--
{
  ****"@context": {
    "modified": {
      "@id": "http://purl.org/dc/terms/modified",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    }
  },****
  ####...####
  "@id": "http://example.com/docs/1",
  "modified": "2010-05-29T14:17:39+02:00"####,
  ...####
}
-->
</pre>

<p>The <em>modified</em> key's value above is automatically type coerced to a
  <em>dateTime</em> value because of the information specified in the
  <code>@context</code>. A <a>JSON-LD processor</a> will interpret the example above
  as follows:</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
  <th>Value Type</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.com/docs/1</td>
  <td>http://purl.org/dc/terms/modified</td>
  <td>2010-05-29T14:17:39+02:00</td>
  <td>xsd:dateTime</td>
</tr>
</tbody>
</table>

<p>The second example uses the expanded form of setting the type information
in the body of a JSON-LD document:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Expanded value with type">
<!--
{
  "@context": {
    "modified": {
      "@id": "http://purl.org/dc/terms/modified"
    }
  },
  ####...####
  "modified": ****{
    "@value": "2010-05-29T14:17:39+02:00",
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
  }****
  ####...####
}
-->
</pre>

<p>Both examples above would generate the value
  <code>2010-05-29T14:17:39+02:00</code> with the type
  <code>http://www.w3.org/2001/XMLSchema#dateTime</code>. Note that it is
  also possible to use a <a>term</a> or a <a>compact IRI</a> to
  express the value of a type.</p>

<p class="note">The <code>@type</code> <a>keyword</a> is also used to associate a type
  with a <a>node</a>. The concept of a <a>node type</a> and
  a <a>value type</a> are different.</p>

<p>A <dfn>node type</dfn> specifies the type of thing
  that is being described, like a person, place, event, or web page. A
  <dfn>value type</dfn> specifies the data type of a particular value, such
  as an integer, a floating point number, or a date.</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Example demonstrating the context-sensitivity for @type">
<!--
{
  ####...####
  "@id": "http://example.org/posts#TripToWestVirginia",
  ****"@type": "http://schema.org/BlogPosting"****,  ####← This is a node type####
  "modified": {
    "@value": "2010-05-29T14:17:39+02:00",
    ****"@type": "http://www.w3.org/2001/XMLSchema#dateTime"****  ####← This is a value type####
  }
  ####...####
}
-->
</pre>

<p>The first use of <code>@type</code> associates a <a>node type</a>
  (<code>http://schema.org/BlogPosting</code>) with the <a>node</a>,
  which is expressed using the <code>@id</code> <a>keyword</a>.
  The second use of <code>@type</code> associates a <a>value type</a>
  (<code>http://www.w3.org/2001/XMLSchema#dateTime</code>) with the
  value expressed using the <code>@value</code> <a>keyword</a>. As a
  general rule, when <code>@value</code> and <code>@type</code> are used in
  the same <a>JSON object</a>, the <code>@type</code>
  <a>keyword</a> is expressing a <a>value type</a>.
  Otherwise, the <code>@type</code> <a>keyword</a> is expressing a
  <a>node type</a>. The example above expresses the following data:</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
  <th>Value Type</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.org/posts#TripToWestVirginia</td>
  <td>rdf:type</td>
  <td>schema:BlogPosting</td>
  <td style="text-align:center;">-</td>
</tr>
<tr>
  <td>http://example.org/posts#TripToWestVirginia</td>
  <td>dcterms:modified</td>
  <td>2010-05-29T14:17:39+02:00</td>
  <td>xsd:dateTime</td>
</tr>
</tbody>
</table>

</section>

<section class="informative">
<h2>Type Coercion</h2>

<p>JSON-LD supports the coercion of values to particular data types.
Type <dfn>coercion</dfn> allows someone deploying JSON-LD to coerce the incoming or
outgoing values to the proper data type based on a mapping of data type <a>IRIs</a> to
<a>terms</a>. Using type coercion, value representation is preserved without requiring
the data type to be specified with each piece of data.</p>

<p>Type coercion is specified within an <a>expanded term definition</a>
  using the <code>@type</code> key. The value of this key expands to an <a>IRI</a>.
  Alternatively, the <a>keyword</a> <code>@id</code> or <code>@vocab</code> may be used
  as value to indicate that within the body of a JSON-LD document, a <a>string</a> value of a
  <a>term</a> coerced to <code>@id</code> or <code>@vocab</code> is to be interpreted as an
  <a>IRI</a>. The difference between <code>@id</code> and <code>@vocab</code> is how values are expanded
  to <a>absolute IRIs</a>. <code>@vocab</code> first tries to expand the value
  by interpreting it as <a>term</a>. If no matching <a>term</a> is found in the
  <a>active context</a>, it tries to expand it as <a>compact IRI</a> or <a>absolute IRI</a>
  if there's a colon in the value; otherwise, it will expand the value using the
  <a data-lt="active context">active context's</a> <a>vocabulary mapping</a>, if present.
  Values coerced to <code>@id</code> in contrast are expanded as
  <a>compact IRI</a> or <a>absolute IRI</a> if a colon is present; otherwise, they are interpreted
  as <a>relative IRI</a>.</p>

<p><a>Terms</a> or <a>compact IRIs</a> used as the value of a
  <code>@type</code> key may be defined within the same context. This means that one may specify a
  <a>term</a> like <code>xsd</code> and then use <code>xsd:integer</code> within the same
  context definition.</p>

<p>The example below demonstrates how a JSON-LD author can coerce values to
<a>typed values</a> and <a>IRIs</a>.</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Expanded term definition with types">
<!--
{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": ****{
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": "xsd:integer"
    }****,
    "homepage": ****{
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }****
  },
  "@id": "http://example.com/people#john",
  "name": "John Smith",
  "age": ****"41"****,
  "homepage": ****[
    "http://personal.example.org/",
    "http://work.example.com/jsmith/"
  ]****
}
-->
</pre>

<p>The example shown above would generate the following data.</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
  <th>Value Type</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.com/people#john</td>
  <td>foaf:name</td>
  <td>John Smith</td>
  <td>&nbsp;</td>
</tr>
<tr>
  <td>http://example.com/people#john</td>
  <td>foaf:age</td>
  <td>41</td>
  <td>xsd:integer</td>
</tr>
<tr>
  <td rowspan="2">http://example.com/people#john</td>
  <td rowspan="2">foaf:homepage</td>
  <td>http://personal.example.org/</td>
  <td><a>IRI</a></td>
</tr>
<tr>
  <td>http://work.example.com/jsmith/</td>
  <td><a>IRI</a></td>
</tr>
</tbody>
</table>

<p>Terms may also be defined using <a>absolute IRIs</a>
  or <a>compact IRIs</a>. This allows coercion rules
  to be applied to keys which are not represented as a simple <a>term</a>.
  For example:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Term definitions using compact and absolute IRIs">
<!--
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "****foaf:age****": {
      ****"@id": "http://xmlns.com/foaf/0.1/age"****,
      "@type": "xsd:integer"
    },
    "****http://xmlns.com/foaf/0.1/homepage****": {
      "@type": "@id"
    }
  },
  "foaf:name": "John Smith",
  "****foaf:age****": "41",
  "****http://xmlns.com/foaf/0.1/homepage****": [
    "http://personal.example.org/",
    "http://work.example.com/jsmith/"
  ]
}
-->
</pre>

<p>In this case the <code>@id</code> definition in the term definition is optional.
  If it does exist, the <a>compact IRI</a> or <a>IRI</a> representing
  the term will always be expanded to <a>IRI</a> defined by the <code>@id</code>
  key&mdash;regardless of whether a prefix is defined or not.</p>

<p>Type coercion is always performed using the unexpanded value of the key. In the
  example above, that means that type coercion is done looking for <code>foaf:age</code>
  in the <a>active context</a> and not for the corresponding, expanded
  <a>IRI</a> <code>http://xmlns.com/foaf/0.1/age</code>.</p>

<p class="note">Keys in the context are treated as <a>terms</a> for the purpose of
  expansion and value coercion. At times, this may result in multiple representations for the same expanded IRI.
  For example, one could specify that <code>dog</code> and <code>cat</code> both expanded to <code>http://example.com/vocab#animal</code>.
  Doing this could be useful for establishing different type coercion or language specification rules. It also allows a <a>compact IRI</a> (or even an
  absolute <a>IRI</a>) to be defined as something else entirely. For example, one could specify that
  the <a>term</a> <code>http://example.org/zoo</code> should expand to
  <code>http://example.org/river</code>, but this usage is discouraged because it would lead to a
  great deal of confusion among developers attempting to understand the JSON-LD document.</p>


</section>

<section class="informative">
  <h2>Embedding</h2>

  <p><dfn>Embedding</dfn> is a JSON-LD feature that allows an author to
    use <a>node objects</a> as
    <a>property</a> values. This is a commonly used mechanism for
    creating a parent-child relationship between two <a>nodes</a>.</p>

  <p>Without embedding, <a>node objects</a> can be linked by referencing the
    identifier of another <a>node object</a>. For example:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Referencing node objects">
  <!--
  [{
    "@context": {
      "@vocab": "http://schema.org/",
      ****"knows": {"@type": "@id"}****
    },
    "name": "Manu Sporny",
    "@type": "Person",
    ****"knows": "http://foaf.me/gkellogg#me"****
  }, {
    "@id": "http://foaf.me/gkellogg#me",
    "@type": "Person",
    "name": "Gregg Kellogg"
  }]
  -->
  </pre>

  <p>The previous example describes two <a>node objects</a>, for Manu and Gregg, with
    the <code>knows</code> property defined to treat string values as identifiers.
    Embedding allows the <a>node object</a> for Gregg to be <em>embedded</em> as a value
    of the <code>knows</code> property:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Embedding a node object as property value of another node object">
  <!--
  {
    "@context": {
      "@vocab": "http://schema.org/"
    },
    "name": "Manu Sporny",
    ****"knows": {****
      "@id": "http://foaf.me/gkellogg#me",
      "@type": "Person",
      "name": "Gregg Kellogg"
    ****}****
  }
  -->
  </pre>

  <p>A <a>node object</a>, like the one used above, may be used in
    any value position in the body of a JSON-LD document. Note that <a
    href="#type-coercion">type coercion</a> of the <code>knows</code> property
    is not required, as the value is not a string.</p>
</section>

<section class="informative">
  <h2>Advanced Context Usage</h2>

  <p>Section <a href="#the-context"></a> introduced the basics of what makes
  JSON-LD work. This section expands on the basic principles of the
  <a>context</a> and demonstrates how more advanced use cases can
  be achieved using JSON-LD. </p>

  <p>In general, contexts may be used at any time a
    <a>JSON object</a> is defined.
    The only time that one cannot express a context is as a direct child of another context definition.
    For example, a <a>JSON-LD document</a> may use more than one context at different
    points in a document:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Using multiple contexts">
  <!--
  [
    {
      ****"@context": "http://example.org/contexts/person.jsonld",****
      "name": "Manu Sporny",
      "homepage": "http://manu.sporny.org/",
      "depiction": "http://twitter.com/account/profile_image/manusporny"
    },
    {
      ****"@context": "http://example.org/contexts/place.jsonld",****
      "name": "The Empire State Building",
      "description": "The Empire State Building is a 102-story landmark in New York City.",
      "geo": {
        "latitude": "40.75",
        "longitude": "73.98"
      }
    }
  ]
  -->
  </pre>

  <p>Duplicate context <a>terms</a> are overridden using a
    most-recently-defined-wins mechanism.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Scoped contexts within node objects">
  <!--
  {
    ****"@context": {
      "name": "http://example.com/person#name",
      "details": "http://example.com/person#details"
    }****,
    "****name****": "Markus Lanthaler",
    ####...####
    "details": {
      ****"@context": {
        "name": "http://example.com/organization#name"
      }****,
      "****name****": "Graz University of Technology"
    }
  }
  -->
  </pre>

  <p>In the example above, the <code>name</code> <a>term</a> is overridden
    in the more deeply nested <code>details</code> structure. Note that this is
    rarely a good authoring practice and is typically used when working with
    legacy applications that depend on a specific structure of the
    <a>JSON object</a>. If a <a>term</a> is redefined within a
    context, all previous rules associated with the previous definition are
    removed. If a <a>term</a> is redefined to <code>null</code>,
    the <a>term</a> is effectively removed from the list of
    <a>terms</a> defined in the <a>active context</a>.</p>

  <p>Multiple contexts may be combined using an <a>array</a>, which is processed
    in order. The set of contexts defined within a specific <a>JSON object</a> are
    referred to as <a>local contexts</a>. The
    <a>active context</a> refers to the accumulation of
    <a>local contexts</a> that are in scope at a
    specific point within the document. Setting a <a>local context</a>
    to <code>null</code> effectively resets the <a>active context</a>
    to an empty context. The following example specifies an external context
    and then layers an embedded context on top of the external context:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Combining external and local contexts">
  <!--
  {
    ****"@context": [
      "https://json-ld.org/contexts/person.jsonld",
      {
        "pic": "http://xmlns.com/foaf/0.1/depiction"
      }
    ],****
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/",
    ****"pic": "http://twitter.com/account/profile_image/manusporny"****
  }
  -->
  </pre>

  <p class="note">When possible, the <a>context</a> definition should be put
    at the top of a JSON-LD document. This makes the document easier to read and
    might make streaming parsers more efficient. Documents that do not have the
    <a>context</a> at the top are still conformant JSON-LD.</p>

  <p class="note">To avoid forward-compatibility issues, <a>terms</a>
    starting with an&nbsp;<code>@</code> character are to be avoided as they
    might be used as <a>keyword</a> in future versions
    of JSON-LD. Terms starting with an&nbsp;<code>@</code> character that are not
    <a data-lt="keyword">JSON-LD 1.1 keywords</a> are treated as any other term, i.e.,
    they are ignored unless mapped to an <a>IRI</a>. Furthermore, the use of
    empty <a>terms</a> (<code>""</code>) is not allowed as
    not all programming languages are able to handle empty JSON keys.</p>
</section>

<section class="normative">
  <h2>Interpreting JSON as JSON-LD</h2>

  <p>Ordinary JSON documents can be interpreted as JSON-LD
    by providing an explicit JSON-LD <a>context</a> document. One way
    to provide this is by using referencing a JSON-LD
    <a>context</a> document in an <a data-cite="RFC5988#section-5">HTTP Link Header</a>.
    Doing so allows JSON to be unambiguously machine-readable without requiring developers to drastically
    change their documents and provides an upgrade path for existing infrastructure
    without breaking existing clients that rely on the <code>application/json</code>
    media type or a media type with a <code>+json</code> suffix as defined in
    [[RFC6839]].</p>

  <p>In order to use an external context with an ordinary JSON document,
    when retrieving an ordinary JSON document via HTTP, processors MUST
    retrieve any <a>JSON-LD document</a> referenced by a
    <a data-cite="RFC5988#section-5">Link Header</a> with:</p>

  <ul>
    <li><code>rel="http://www.w3.org/ns/json-ld#context"</code>, and</li>
    <li><code>type="application/ld+json"</code>.</li>
  </ul>

  <p>The referenced document MUST have a top-level <a>JSON object</a>.
    The <code>@context</code> subtree within that object is added to the top-level
    <a>JSON object</a> of the referencing document. If an <a>array</a>
    is at the top-level of the referencing document and its items are
    <a>JSON objects</a>, the <code>@context</code>
    subtree is added to all <a>array</a> items. All extra information located outside
    of the <code>@context</code> subtree in the referenced document MUST be
    discarded. Effectively this means that the <a>active context</a> is
    initialized with the referenced external <a>context</a>. A response MUST NOT
    contain more than one <a data-cite="RFC5988#section-5">HTTP Link Header</a> [[!RFC5988]] using the
    <code>http://www.w3.org/ns/json-ld#context</code> link relation.</p>

  <p>Other mechanisms for providing a JSON-LD Context MAY be described for other
    URI schemes.</p>

  <p>The JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]]
    provides for an <a data-cite="JSON-LD11CG-API#dom-jsonldoptions-expandcontext">expandContext</a> option for specifying
    a <a>context</a> to use when expanding JSON documents programatically.</p>

  <p>The following example demonstrates the use of an external context with an
    ordinary JSON document over HTTP:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       data-content-type="http"
       title="Referencing a JSON-LD context from a JSON document via an HTTP Link Header">
  <!--
  GET /ordinary-json-document.json HTTP/1.1
  Host: example.com
  Accept: application/ld+json,application/json,*/*;q=0.1

  ====================================

  HTTP/1.1 200 OK
  ####...####
  Content-Type: ****application/json****
  ****Link: <https://json-ld.org/contexts/person.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"****

  {
    "name": "Markus Lanthaler",
    "homepage": "http://www.markus-lanthaler.com/",
    "image": "http://twitter.com/account/profile_image/markuslanthaler"
  }
  -->
  </pre>

  <p>Please note that <a>JSON-LD documents</a>
    served with the <code>application/ld+json</code>
    media type MUST have all context information, including references to external
    contexts, within the body of the document. Contexts linked via a
    <code>http://www.w3.org/ns/json-ld#context</code> <a data-cite="RFC5988#section-5">HTTP Link Header</a> MUST be
    ignored for such documents.</p>
</section>

<section class="informative">
  <h2>String Internationalization</h2>

  <p>At times, it is important to annotate a <a>string</a>
    with its language. In JSON-LD this is possible in a variety of ways.
    First, it is possible to define a <a>default language</a> for a JSON-LD document
    by setting the <code>@language</code> key in the <a>context</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Setting the default language of a JSON-LD document">
  <!--
  {
    ****"@context": {
      ####...####
      "@language": "ja"
    }****,
    "name": ****"花澄"****,
    "occupation": ****"科学者"****
  }
  -->
  </pre>

  <p>The example above would associate the <code>ja</code> language
    code with the two <a>strings</a> <em>花澄</em> and <em>科学者</em>.
    <a data-cite="BCP47#section-2">Languages codes</a> are defined in [[!BCP47]]. The <a>default language</a> applies to all
    <a>string</a> values that are not <a href="#type-coercion">type coerced</a>.</p>

  <p>To clear the <a>default language</a> for a subtree, <code>@language</code> can
    be set to <code>null</code> in a <a>local context</a> as follows:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Clearing default language">
  <!--
  {
    "@context": {
      ####...####
      "@language": "ja"
    },
    "name": "花澄",
    "details": {
      ****"@context": {
        "@language": null
      }****,
      "occupation": "Ninja"
    }
  }
  -->
  </pre>

  <p>Second, it is possible to associate a language with a specific <a>term</a>
    using an <a>expanded term definition</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Expanded term definition with language">
  <!--
  {
    "@context": {
      ####...####
      "ex": "http://example.com/vocab/",
      "@language": "ja",
      "name": { "@id": "ex:name", ****"@language": null**** },
      "occupation": { "@id": "ex:occupation" },
      "occupation_en": { "@id": "ex:occupation", ****"@language": "en"**** },
      "occupation_cs": { "@id": "ex:occupation", ****"@language": "cs"**** }
    },
    ****"name": "Yagyū Muneyoshi",
    "occupation": "忍者",
    "occupation_en": "Ninja",
    "occupation_cs": "Nindža"****####,
    ...####
  }
  -->
  </pre>

  <p>The example above would associate <em>忍者</em> with the specified default
    language code <code>ja</code>, <em>Ninja</em> with the language code
    <code>en</code>, and <em>Nindža</em> with the language code <code>cs</code>.
    The value of <code>name</code>, <em>Yagyū Muneyoshi</em> wouldn't be
    associated with any language code since <code>@language</code> was reset to
    <a>null</a> in the <a>expanded term definition</a>.</p>

  <p class="note">Language associations are only applied to plain
    <a>strings</a>. <a>Typed values</a>
    or values that are subject to <a href="#type-coercion">type coercion</a>
    are not language tagged.</p>

  <p>Just as in the example above, systems often need to express the value of a
    property in multiple languages. Typically, such systems also try to ensure that
    developers have a programmatically easy way to navigate the data structures for
    the language-specific data. In this case, <a>language maps</a>
    may be utilized.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Language map expressing a property in three languages">
  <!--
  {
    "@context": {
      ####...####
      "occupation": { "@id": "ex:occupation", ****"@container": "@language"**** }
    },
    "name": "Yagyū Muneyoshi",
    "occupation": ****{
      "ja": "忍者",
      "en": "Ninja",
      "cs": "Nindža"
    }****
    ####...####
  }
  -->
  </pre>

  <p>The example above expresses exactly the same information as the previous
    example but consolidates all values in a single property. To access the
    value in a specific language in a programming language supporting dot-notation
    accessors for object properties, a developer may use the
    <code>property.language</code> pattern. For example, to access the occupation
    in English, a developer would use the following code snippet:
    <code>obj.occupation.en</code>.</p>

  <p>Third, it is possible to override the <a>default language</a> by using a
    <a>value object</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Overriding default language using an expanded value">
  <!--
  {
    "@context": {
      ####...####
      "@language": "ja"
    },
    "name": "花澄",
    "occupation": ****{
      "@value": "Scientist",
      "@language": "en"
    }****
  }
  -->
  </pre>

  <p>This makes it possible to specify a plain string by omitting the
    <code>@language</code> tag or setting it to <code>null</code> when expressing
    it using a <a>value object</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Removing language information using an expanded value">
  <!--
  {
    "@context": {
      ####...####
      "@language": "ja"
    },
    "name": ****{
      "@value": "Frank"
    }****,
    "occupation": {
      "@value": "Ninja",
      "@language": "en"
    },
    "speciality": "手裏剣"
  }
  -->
  </pre>

</section>

<section class="informative">
  <h2>IRI Expansion within a Context</h2>
  <p>In general, normal IRI expansion rules apply
    anywhere an IRI is expected (see <a class="sectionRef" href="#iris"></a>). Within
    a <a>context</a> definition, this can mean that terms defined
    within the context may also be used within that context as long as
    there are no circular dependencies. For example, it is common to use
    the <code>xsd</code> namespace when defining <a>typed values</a>:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="IRI expansion within a context">
<!--
{
  "@context": {
    ****"xsd": "http://www.w3.org/2001/XMLSchema#"****,
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": {
      "@id": "http://xmlns.com/foaf/0.1/age",
      "@type": ****"xsd:integer"****
    },
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage",
      "@type": "@id"
    }
  }####,
  ...####
}
-->
</pre>

<p>In this example, the <code>xsd</code> <a>term</a> is defined
  and used as a <a>prefix</a> for the <code>@type</code> coercion
  of the <code>age</code> property.</p>

<p><a>Terms</a> may also be used when defining the IRI of another
<a>term</a>:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Using a term to define the IRI of another term within a context">
<!--
{
  "@context": {
    ****"foaf": "http://xmlns.com/foaf/0.1/"****,
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": ****"foaf:name"****,
    "age": {
      "@id": ****"foaf:age"****,
      "@type": "xsd:integer"
    },
    "homepage": {
      "@id": ****"foaf:homepage"****,
      "@type": "@id"
    }
  }####,
  ...####
}
-->
</pre>

<p><a>Compact IRIs</a>
  and <a>IRIs</a> may be used on the left-hand side of a
  <a>term</a> definition.</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Using a compact IRI as a term">
<!--
{
  "@context": {
    ****"foaf": "http://xmlns.com/foaf/0.1/"****,
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "****foaf:age****": {
      "@type": "xsd:integer"
    },
    "****foaf:homepage****": ****{
      "@type": "@id"
    }****
  }####,
  ...####
}
-->
</pre>

<p>
In this example, the <a>compact IRI</a> form is used in two different
ways.
In the first approach, <code>foaf:age</code> declares both the
<a>IRI</a> for the <a>term</a> (using short-form) as well as the
<code>@type</code> associated with the <a>term</a>. In the second
approach, only the <code>@type</code> associated with the <a>term</a> is
specified. The full <a>IRI</a> for
<code>foaf:homepage</code> is determined by looking up the <code>foaf</code>
<a>prefix</a> in the
<a>context</a>.
</p>

<p>
<a>Absolute IRIs</a> may also be used in the key position in a <a>context</a>:
</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Associating context definitions with absolute IRIs">
<!--
{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": "foaf:name",
    "foaf:age": {
      "@id": "foaf:age",
      "@type": "xsd:integer"
    },
    "****http://xmlns.com/foaf/0.1/homepage****": {
      "@type": "@id"
    }
  }####,
  ...####
}
-->
</pre>

<p>In order for the <a>absolute IRI</a> to match above, the <a>absolute IRI</a>
  needs to be used in the <a>JSON-LD document</a>. Also note that <code>foaf:homepage</code>
  will not use the <code>{ "@type": "@id" }</code> declaration because
  <code>foaf:homepage</code> is not the same as <code>http://xmlns.com/foaf/0.1/homepage</code>.
  That is, <a>terms</a> are looked up in a <a>context</a> using
  direct string comparison before the <a>prefix</a> lookup mechanism is applied.</p>

<p class="note">While it is possible to define a <a>compact IRI</a>, or
  an <a>absolute IRI</a> to expand to some other unrelated <a>IRI</a>
  (for example, <code>foaf:name</code> expanding to
  <code>http://example.org/unrelated#species</code>), such usage is strongly
  discouraged.</p>

<p>The only exception for using terms in the <a>context</a> is that
  circular definitions are not allowed. That is,
  a definition of <em>term1</em> cannot depend on the
  definition of <em>term2</em> if <em>term2</em> also depends on
  <em>term1</em>. For example, the following <a>context</a> definition
  is illegal:</p>
<pre class="example nohighlight" data-transform="updateExample"
     title="Illegal circular definition of terms within a context">
<!--
{
  "@context": {
    ****"term1": "term2:foo",
    "term2": "term1:bar"****
  }####,
  ...####
}
-->
</pre>
</section>

<section class="informative">
<h2>Sets and Lists</h2>

<p>A JSON-LD author can express multiple values in a compact way by using
  <a>arrays</a>. Since graphs do not describe ordering for links
  between nodes, arrays in JSON-LD do not provide an ordering of the
  contained elements by default. This is exactly the opposite from regular JSON
  arrays, which are ordered by default. For example, consider the following
  simple document:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Multiple values with no inherent order">
<!--
{
  ####...####
  "@id": "http://example.org/people#joebob",
  "foaf:nick": ****[ "joe", "bob", "JB" ]****####,
  ...####
}
-->
</pre>

<p>The example shown above would result in the following data being generated,
  each relating the node to an individual value, with no inherent order:</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.org/people#joebob</td>
  <td>foaf:nick</td>
  <td>joe</td>
</tr>
<tr>
  <td>http://example.org/people#joebob</td>
  <td>foaf:nick</td>
  <td>bob</td>
</tr>
<tr>
  <td>http://example.org/people#joebob</td>
  <td>foaf:nick</td>
  <td>JB</td>
</tr>
</tbody>
</table>

<p>Multiple values may also be expressed using the expanded form:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Using an expanded form to set multiple values">
<!--
{
  "@id": "http://example.org/articles/8",
  "dcterms:title": **** [
    {
      "@value": "Das Kapital",
      "@language": "de"
    },
    {
      "@value": "Capital",
      "@language": "en"
    }
  ]****
}-->
</pre>

<p>The example shown above would generate the following data, again with
  no inherent order:</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
  <th>Language</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.org/articles/8</td>
  <td>dcterms:title</td>
  <td>Das Kapital</td>
  <td>de</td>
</tr>
<tr>
  <td>http://example.org/articles/8</td>
  <td>dcterms:title</td>
  <td>Capital</td>
  <td>en</td>
</tr>
</tbody>
</table>

<p>Although multiple values of a property are typically of the same type,
  JSON-LD places no restriction on this, and a property may have values
  of different types:</p>

<pre class="example nohighlight" data-transform="updateExample"
     title="Multiple array values of different types">
<!--
{
  "@id": "http://example.org/people#michael",
  "dcterms:name": [
    "Michael",
    {"@value": "Mike"},
    {"@value": "Miguel", "@language": "es"},
    { "@id": "https://www.wikidata.org/wiki/Q4927524" },
    42
  ]
}
-->
</pre>

<p>The example shown above would generate the following data, also with
  no inherent order:</p>

<table class="example">
<thead><tr>
  <th>Subject</th>
  <th>Property</th>
  <th>Value</th>
  <th>Language</th>
  <th>Value Type</th>
</tr></thead>
<tbody>
<tr>
  <td>http://example.org/people#michael</td>
  <td>dcterms:name</td>
  <td>Michael</td>
  <td></td>
  <td></td>
</tr>
<tr>
  <td>http://example.org/people#michael</td>
  <td>dcterms:name</td>
  <td>Mike</td>
  <td></td>
  <td></td>
</tr>
<tr>
  <td>http://example.org/people#michael</td>
  <td>dcterms:name</td>
  <td>Miguel</td>
  <td>es</td>
  <td></td>
</tr>
<tr>
  <td>http://example.org/people#michael</td>
  <td>dcterms:name</td>
  <td>https://www.wikidata.org/wiki/Q4927524</td>
  <td></td>
  <td></td>
</tr>
<tr>
  <td>http://example.org/people#michael</td>
  <td>dcterms:name</td>
  <td>42</td>
  <td></td>
  <td>xsd:integer</td>
</tr>
</tbody>
</table>

<p>As the notion of ordered collections is rather important in data
  modeling, it is useful to have specific language support. In JSON-LD,
  a list may be represented using the <code>@list</code> <a>keyword</a> as follows:</p>
<pre class="example nohighlight" data-transform="updateExample"
     title="An ordered collection of values in JSON-LD">
<!--
{
  ####...####
  "@id": "http://example.org/people#joebob",
  "foaf:nick": ****{
    "@list": [ "joe", "bob", "jaybee" ]
  }****####,
  ...####
}
-->
</pre>

<p>This describes the use of this <a>array</a> as being ordered,
  and order is maintained when processing a document. If every use of a given multi-valued
  property is a list, this may be abbreviated by setting <code>@container</code>
  to <code>@list</code> in the <a>context</a>:</p>
<pre class="example nohighlight" data-transform="updateExample"
     title="Specifying that a collection is ordered in the context">
<!--
{
  ****"@context": {
    ####...####
    "nick": {
      "@id": "http://xmlns.com/foaf/0.1/nick",
      "@container": "@list"
    }
  }****,
  ####...####
  "@id": "http://example.org/people#joebob",
  "nick": ****[ "joe", "bob", "jaybee" ]****####,
  ...####
}
-->
</pre>

<p class="note">List of lists in the form of <a>list objects</a>
  are not allowed in this version of JSON-LD. This decision was made due to the
  extreme amount of added complexity when processing lists of lists.</p>

<p>While <code>@list</code> is used to describe <em>ordered lists</em>,
  the <code>@set</code> keyword is used to describe <em>unordered sets</em>.
  The use of <code>@set</code> in the body of a JSON-LD document
  is optimized away when processing the document, as it is just syntactic
  sugar. However, <code>@set</code> is helpful when used within the context
  of a document.
  Values of terms associated with an <code>@set</code> or <code>@list</code> container
  are always represented in the form of an <a>array</a>,
  even if there is just a single value that would otherwise be optimized to
  a non-array form in compact form (see
  <a class="sectionRef" href="#compacted-document-form"></a>). This makes post-processing of
  JSON-LD documents easier as the data is always in array form, even if the
  array only contains a single value.</p>

</section>

<section class="informative">
  <h2>Reverse Properties</h2>

  <p>JSON-LD serializes directed <a>graphs</a>. That means that
    every <a>property</a> points from a <a>node</a> to another <a>node</a>
    or <a data-lt="JSON-LD value">value</a>. However, in some cases, it is desirable
    to serialize in the reverse direction. Consider for example the case where a person
    and its children should be described in a document. If the used vocabulary does not
    provide a <em>children</em> <a>property</a> but just a <em>parent</em>
    <a>property</a>, every <a>node</a> representing a child would have to
    be expressed with a <a>property</a> pointing to the parent as in the following
    example.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="A document with children linking to their parent">
  <!--
  [
    {
      ****"@id": "#homer"****,
      "http://example.com/vocab#name": "Homer"
    }, {
      "@id": "#bart",
      "http://example.com/vocab#name": "Bart",
      ****"http://example.com/vocab#parent": { "@id": "#homer" }****
    }, {
      "@id": "#lisa",
      "http://example.com/vocab#name": "Lisa",
      ****"http://example.com/vocab#parent": { "@id": "#homer" }****
    }
  ]
  -->
  </pre>

  <p>Expressing such data is much simpler by using JSON-LD's <code>@reverse</code>
    <a>keyword</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="A person and its children using a reverse property">
  <!--
  {
    "@id": "#homer",
    "http://example.com/vocab#name": "Homer",
    ****"@reverse"****: {
      ****"http://example.com/vocab#parent"****: [
        {
          "@id": "#bart",
          "http://example.com/vocab#name": "Bart"
        }, {
          "@id": "#lisa",
          "http://example.com/vocab#name": "Lisa"
        }
      ]
    }
  }
  -->
  </pre>

  <p>The <code>@reverse</code> <a>keyword</a> can also be used in
    <a>expanded term definitions</a>
    to create reverse properties as shown in the following example:</p>


  <pre class="example nohighlight" data-transform="updateExample"
       title="Using @reverse to define reverse properties">
  <!--
  {
    "@context": { "name": "http://example.com/vocab#name",
      ****"children": { "@reverse": "http://example.com/vocab#parent" }****
    },
    "@id": "#homer",
    "name": "Homer",
    ****"children"****: [
      {
        "@id": "#bart",
        "name": "Bart"
      }, {
        "@id": "#lisa",
        "name": "Lisa"
      }
    ]
  }
  -->
  </pre>
</section>

<section class="informative changed">
  <h2>Scoped Contexts</h2>

  <p>An <a>expanded term definition</a> can include a <code>@context</code>
    property, which defines a <a>context</a> (an <dfn>embedded context</dfn>) for <a data-lt="JSON-LD
    value">values</a> of properties defined using that <a>term</a>. This allows
    values to use <a>term definitions</a>, <a>base IRI</a>,
    <a>vocabulary mapping</a> or <a>default language</a> which is different from the
    <a>node object</a> they are contained in, as if the
    <a>context</a> was specified within the value itself.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Defining an @context within a term definition">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "name": "http://schema.org/name",
      "interest": {
        "@id": "http://xmlns.com/foaf/0.1/interest",
        ****"@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}****
      }
    },
    "name": "Manu Sporny",
    "interest": ****{
      "@id": "https://www.w3.org/TR/json-ld/",
      "name": "JSON-LD",
      "topic": "Linking Data"
    }****
  }
  -->
  </pre>

  <p>In this case, the social profile is defined using the schema.org vocabulary, but interest is imported from FOAF, and is used to define a node describing one of Manu's interests where those properties now come from the FOAF vocabulary.</p>

  <p>Expanding this document, uses a combination of terms defined in the outer context, and those defined specifically for that term in an <a>embedded context</a>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Expanded document using a scoped context">
  <!--
  [{
    "http://schema.org/name": [{"@value": "Manu Sporny"}],
    "http://xmlns.com/foaf/0.1/interest": [{
      "@id": "https://www.w3.org/TR/json-ld/",
      "http://schema.org/name": [{"@value": "JSON-LD"}],
      ****"http://xmlns.com/foaf/0.1/topic": [{"@value": "Linking Data"}]****
    }]
  }]
  -->
  </pre>

  <p>Scoping can also be performed using a term used as a value of <code>@type</code>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Defining an @context within a term definition used on @type">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "name": "http://schema.org/name",
      "interest": "http://xmlns.com/foaf/0.1/interest",
      ****"Document"****: {
        "@id": "http://xmlns.com/foaf/0.1/Document",
        ****"@context": {"@vocab": "http://xmlns.com/foaf/0.1/"}****
      }
    },
    "@type": "Person",
    "name": "Manu Sporny",
    "interest": {
      "@id": "https://www.w3.org/TR/json-ld/",
      ****"@type": "Document"****,
      "name": "JSON-LD",
      "topic": "Linking Data"
    }
  }
  -->
  </pre>

  <p>Scoping on <code>@type</code> is useful when common properties are used to
    relate things of different types, where the vocabularies in use within
    different entities calls for different context scoping. For example,
    <code>hasPart</code>/<code>partOf</code> may be common terms used in a document, but mean
    different things depending on the context.</p>

  <p>When expanding, each value of <code>@type</code> is considered
    (ordering them lexographically) where that value is also a <a>term</a> in
    the <a>active context</a> having its own <a>embedded context</a>. If so, that
    <a>embedded context</a> is applied to the <a>active context</a>. When compacting, if
    a <a>term</a> is chosen to represent an IRI used as a value of <code>@type</code> where that
    <a>term definition</a> also has an <a>embedded context</a>, it is then applied to the
    <a>active context</a> to affect further compaction.</p>

  <p class="note">The values of <code>@type</code> are unordered, so if multiple
    types are listed, the order that scoped contexts are applied is based on
    lexicographical ordering.</p>

  <p class="note">If a <a>term</a> defines a scoped context, and then that term
    is later re-defined, the association of the context defined in the earlier
    <a>expanded term definition</a> is lost
    within the scope of that re-definition. This is consistent with
    <a>term definitions</a> of a term overriding previous term definitions from
    earlier less deeply nested definitions, as discussed in
    <a href="#advanced-context-usage" class="sectionRef"></a>.</p>

  <p class="note">Scoped Contexts are a new feature in JSON-LD 1.1, requiring
    <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
</section>


<section class="informative">
  <h2>Named Graphs</h2>

  <p>At times, it is necessary to make statements about a <a>graph</a>
    itself, rather than just a single <a>node</a>. This can be done by
    grouping a set of <a>nodes</a> using the <code>@graph</code>
    <a>keyword</a>. A developer may also name data expressed using the
    <code>@graph</code> <a>keyword</a> by pairing it with an
    <code>@id</code> <a>keyword</a> as shown in the following example:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Identifying and making statements about a graph">
  <!--
  {
    "@context": {
      "generatedAt": {
        "@id": "http://www.w3.org/ns/prov#generatedAtTime",
        "@type": "http://www.w3.org/2001/XMLSchema#date"
      },
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "name": "http://xmlns.com/foaf/0.1/name",
      "knows": "http://xmlns.com/foaf/0.1/knows"
    },
    ****"@id": "_:graph",
    "generatedAt": "2012-04-09",
    "@graph":**** [
      {
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "Person",
        "name": "Manu Sporny",
        "knows": "http://greggkellogg.net/foaf#me"
      }, {
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": "Person",
        "name": "Gregg Kellogg",
        "knows": "http://manu.sporny.org/about#manu"
      }
    ]
  }
  -->
  </pre>

  <p>The example above expresses a <a>named graph</a> that is identified
    by the <a>Blank Node identifier</a> <code>_:graph</code>. That
    graph is composed of the statements about Manu and Gregg. Metadata about
    the graph itself is expressed via the <code>generatedAt</code> property,
    which specifies when the graph was generated. An alternative view of the
    information above is represented in table form below:</p>

  <table class="example">
  <thead><tr>
    <th>Graph</th>
    <th>Subject</th>
    <th>Property</th>
    <th>Value</th>
    <th>Value Type</th>
  </tr></thead>
  <tbody>
  <tr>
    <td>&nbsp;</td>
    <td>_:graph</td>
    <td>prov:generatedAtTime</td>
    <td>2012-04-09</td>
    <td>xsd:date</td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>xsd:type</td>
    <td>foaf:Person</td>
    <td></td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>foaf:name</td>
    <td>Manu Sporny</td>
    <td></td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>foaf:knows</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td></td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>xsd:type</td>
    <td>foaf:Person</td>
    <td></td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>foaf:name</td>
    <td>Gregg Kellogg</td>
    <td></td>
  </tr>
  <tr>
    <td>_:graph</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>foaf:knows</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td></td>
  </tr>
  </tbody>
  </table>

  <p>When a JSON-LD document's top-level structure is an
    <a data-lt="JSON object">object</a> that contains no other
    <a>properties</a> than <code>@graph</code> and
    optionally <code>@context</code> (properties that are not mapped to an
    <a>IRI</a> or a <a>keyword</a> are ignored),
    <code>@graph</code> is considered to express the otherwise implicit
    <a>default graph</a>. This mechanism can be useful when a number
    of <a>nodes</a> exist at the document's top level that
    share the same <a>context</a>, which is, e.g., the case when a
    document is <a href="#flattened-document-form">flattened</a>. The
    <code>@graph</code> keyword collects such nodes in an <a>array</a>
    and allows the use of a shared context.</p>

  <pre class="example nohighlight" data-transform="updateExample"
    title="Using @graph to explicitly express the default graph">
  <!--
  {
    "@context": {####...####},
    "****@graph****": [
      {
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "foaf:Person",
        "name": "Manu Sporny",
        "knows": "http://greggkellogg.net/foaf#me"
      }, {
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": "foaf:Person",
        "name": "Gregg Kellogg",
        "knows": "http://manu.sporny.org/about#manu"
      }
    ]
  }
  -->
  </pre>

  <p>In this case, embedding doesn't work as each <a>node object</a>
    references the other. This is equivalent to using multiple
    <a>node objects</a> in array and defining
    the <code>@context</code> within each <a>node object</a>:</p>

  <pre class="example nohighlight" data-transform="updateExample"
    title="Context needs to be duplicated if @graph is not used">
  <!--
  [
    {
      ****"@context": {####...####},****
      "@id": "http://manu.sporny.org/about#manu",
      "@type": "foaf:Person",
      "name": "Manu Sporny",
      "knows": "http://greggkellogg.net/foaf#me"
    },
    {
      ****"@context": {####...####},****
      "@id": "http://greggkellogg.net/foaf#me",
      "@type": "foaf:Person",
      "name": "Gregg Kellogg",
      "knows": "http://manu.sporny.org/about#manu"
    }
  ]
  -->
  </pre>

  <section class="changed">
    <h3>Graph Containers</h3>
    <p>In some cases, it is useful to logically partition data into separate
      graphs, without making this explicit within the JSON expression. For
      example, a JSON document may contain data against which other metadata is
      asserted and it is useful to separate this data in the data model using
      the notion of <a>named graphs</a>, without the syntactic overhead
      associated with the <code>@graph</code> keyword.</p>

    <p>An <a>expanded term definition</a> can use <code>@graph</code> as the
      value of <code>@container</code>. This indicates that values of this
      <a>term</a> should be considered to be <a>named graphs</a>, where the
      <a>graph name</a> is an automatically assigned <a>blank node identifier</a>
      creating an <a>implicitly named graph</a>. When expanded, these become
      <a>simple graph objects</a>.</p>

 <p>An alternative to our example above could use an anonymously <a>named graph</a>
    as follows:</p>

    <pre class="example nohighlight" data-transform="updateExample"
         title="Implicitly named graph">
    <!--
    {
      "@context": {
        "@version": 1.1,
        "generatedAt": {
          "@id": "http://www.w3.org/ns/prov#generatedAtTime",
          "@type": "http://www.w3.org/2001/XMLSchema#date"
        },
        "Person": "http://xmlns.com/foaf/0.1/Person",
        "name": "http://xmlns.com/foaf/0.1/name",
        "knows": "http://xmlns.com/foaf/0.1/knows",
        ****"claim": {
         "@id": "https://w3id.org/credentials#claim",
          "@container": "@graph"
        }****
      },
      ****"generatedAt": "2012-04-09",
      "claim": [****
        {
          "@id": "http://manu.sporny.org/about#manu",
          "@type": "Person",
          "name": "Manu Sporny",
          "knows": "http://greggkellogg.net/foaf#me"
        }, {
          "@id": "http://greggkellogg.net/foaf#me",
          "@type": "Person",
          "name": "Gregg Kellogg",
          "knows": "http://manu.sporny.org/about#manu"
        }
      ****]****
    }
    -->
    </pre>

    <p>The example above expresses a <a>named graph</a> that is identified
      by the <a>blank node identifier</a> <code>_:claim</code>. That
      graph is composed of the statements about Manu and Gregg. Metadata about
      the graph itself is expressed via the <code>generatedAt</code> property,
      which specifies when the graph was generated. An alternative view of the
      information above is represented in table form below:</p>

    <table class="example">
    <thead><tr>
      <th>Graph</th>
      <th>Subject</th>
      <th>Property</th>
      <th>Value</th>
      <th>Value Type</th>
    </tr></thead>
    <tbody>
    <tr>
      <td>&nbsp;</td>
      <td>_:metadata</td>
      <td>prov:generatedAtTime</td>
      <td>2012-04-09</td>
      <td>xsd:date</td>
    </tr>
    <tr>
      <td>&nbsp;</td>
      <td>_:metadata</td>
      <td>cred:claim</td>
      <td>_:claim</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://manu.sporny.org/about#manu</td>
      <td>xsd:type</td>
      <td>foaf:Person</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://manu.sporny.org/about#manu</td>
      <td>foaf:name</td>
      <td>Manu Sporny</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://manu.sporny.org/about#manu</td>
      <td>foaf:knows</td>
      <td>http://greggkellogg.net/foaf#me</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://greggkellogg.net/foaf#me</td>
      <td>xsd:type</td>
      <td>foaf:Person</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://greggkellogg.net/foaf#me</td>
      <td>foaf:name</td>
      <td>Gregg Kellogg</td>
      <td></td>
    </tr>
    <tr>
      <td>_:claim</td>
      <td>http://greggkellogg.net/foaf#me</td>
      <td>foaf:knows</td>
      <td>http://manu.sporny.org/about#manu</td>
      <td></td>
    </tr>
    </tbody>
    </table>

    <p>Expanding this graph results in the following:</p>

    <pre class="example nohighlight" data-transform="updateExample"
         title="Implicitly named graph after expansion">
    <!--
    [{
      ****"http://www.w3.org/ns/prov#generatedAtTime": [{
        "@value": "2012-04-09",
        "@type": "http://www.w3.org/2001/XMLSchema#date"
      }],
      "https://w3id.org/credentials#claim": [{****
        "@graph": [{
          "@id": "http://manu.sporny.org/about#manu",
          "@type": ["http://xmlns.com/foaf/0.1/Person"],
          "http://xmlns.com/foaf/0.1/knows": [{
            "@value": "http://greggkellogg.net/foaf#me"
          }],
          "http://xmlns.com/foaf/0.1/name": [{
            "@value": "Manu Sporny"
          }]
        }, {
          "@id": "http://greggkellogg.net/foaf#me",
          "@type": ["http://xmlns.com/foaf/0.1/Person"],
          "http://xmlns.com/foaf/0.1/knows": [{
            "@value": "http://manu.sporny.org/about#manu"
          }],
          "http://xmlns.com/foaf/0.1/name": [{
            "@value": "Gregg Kellogg"
          }]
        }]
      ****}]****
    }]
    -->
    </pre>

    <p class="note">Strictly speaking, the value of such a <a>term</a>
      is not a <a>named graph</a>, rather it is the <a>graph name</a>
      associated with the <a>named graph</a>, which exists separately within
      the <a>dataset</a>.</p>

    <p class="note">Graph Containers are a new feature in JSON-LD 1.1, requiring
      <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
  </section>
</section>

<section class="informative">
  <h2>Identifying Blank Nodes</h2>

  <p>At times, it becomes necessary to be able to express information without
    being able to uniquely identify the <a>node</a> with an <a>IRI</a>.
    This type of node is called a <a>blank node</a>. JSON-LD does not require
    all nodes to be identified using <code>@id</code>. However, some graph topologies
    may require identifiers to be serializable. Graphs containing loops, e.g., cannot
    be serialized using embedding alone, <code>@id</code> must be used to connect the nodes.
    In these situations, one can use <a>blank node identifiers</a>,
    which look like <a>IRIs</a> using an underscore (<code>_</code>)
    as scheme. This allows one to reference the node locally within the document, but
    makes it impossible to reference the node from an external document. The
    <a>blank node identifier</a> is scoped  to the document in which it is used.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Specifying a local blank node identifier">
  <!--
  {
     ####...####
     "@id": "****_:n1****",
     "name": "Secret Agent 1",
     "knows": {
       "name": "Secret Agent 2",
       "knows": { "@id": "****_:n1****" }
     }
  }
  -->
  </pre>

  <p>The example above contains information about two secret agents that cannot be identified
    with an <a>IRI</a>. While expressing that <em>agent&nbsp;1</em> knows <em>agent&nbsp;2</em>
    is possible without using <a>blank node identifiers</a>,
    it is necessary to assign <em>agent&nbsp;1</em> an identifier so that it can be referenced
    from <em>agent&nbsp;2</em>.</p>
  <p>It is worth noting that blank node identifiers may be relabeled during processing.
    If a developer finds that they refer to the <a>blank node</a> more than once,
    they should consider naming the node using a dereferenceable <a>IRI</a> so that
    it can also be referenced from other documents.</p>
</section>

<section class="informative">
  <h2>Aliasing Keywords</h2>

  <p>Each of the JSON-LD <a>keywords</a>,
    except for <code>@context</code>, may be aliased to application-specific
    keywords. This feature allows legacy JSON content to be utilized
    by JSON-LD by re-using JSON keys that already exist in legacy documents.
    This feature also allows developers to design domain-specific implementations
    using only the JSON-LD <a>context</a>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Aliasing keywords">
  <!--
  {
    "@context": {
      ****"url": "@id"****,
      ****"a": "@type"****,
      "name": "http://xmlns.com/foaf/0.1/name"
    },
    "****url****": "http://example.com/about#gregg",
    "****a****": "http://xmlns.com/foaf/0.1/Person",
    "name": "Gregg Kellogg"
  }
  -->
  </pre>

  <p>In the example above, the <code>@id</code> and <code>@type</code>
    <a>keywords</a> have been given the aliases
    <strong>url</strong> and <strong>a</strong>, respectively.</p>

  <p>Since keywords cannot be redefined, they can also not be aliased to
    other keywords.</p>
</section>

<section class="informative">
  <h2>Data Indexing</h2>

  <p>Databases are typically used to make access to
    data more efficient. Developers often extend this sort of functionality into
    their application data to deliver similar performance gains. Often this
    data does not have any meaning from a Linked Data standpoint, but is
    still useful for an application.</p>

  <p>JSON-LD introduces the notion of <a>index maps</a>
    that can be used to structure data into a form that is
    more efficient to access. The data indexing feature allows an author to
    structure data using a simple key-value map where the keys do not map
    to <a>IRIs</a>. This enables direct access to data
    instead of having to scan an array in search of a specific item.
    In JSON-LD such data can be specified by associating the
    <code>@index</code> <a>keyword</a> with a
    <code>@container</code> declaration in the context:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD">
  <!--
  {
    "@context": {
      "schema": "http://schema.org/",
      "name": "schema:name",
      "body": "schema:articleBody",
      "words": "schema:wordCount",
      "post": {
        "@id": "schema:blogPost",
        ****"@container": "@index"****
      }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    ****"post": {
      "en": {
        "@id": "http://example.com/posts/1/en",
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      },
      "de": {
        "@id": "http://example.com/posts/1/de",
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      }****
    }
  }
  -->
  </pre>

  <p>In the example above, the <strong>post</strong> <a>term</a> has
    been marked as an <a>index map</a>. The <strong>en</strong> and
    <strong>de</strong> keys will be ignored  semantically, but preserved
    syntactically, by the <a>JSON-LD Processor</a>.  This allows a developer to
    access the German version of the <strong>post</strong> using the
    following code snippet: <code>obj.post.de</code>.</p>

  <p>The interpretation of the data above is expressed in
    the table below. Note how the index keys do not appear in the Linked Data
    below, but would continue to exist if the document were compacted or
    expanded (see <a class="sectionRef" href="#compacted-document-form"></a> and
    <a class="sectionRef" href="#expanded-document-form"></a>) using a <a>JSON-LD processor</a>:</p>

  <table class="example">
    <thead><tr>
      <th>Subject</th>
      <th>Property</th>
      <th>Value</th>
    </tr></thead>
    <tbody>
      <tr>
        <td>http://example.com/</td>
        <td>rdf:type</td>
        <td>schema:Blog</td>
      </tr>
      <tr>
        <td>http://example.com/</td>
        <td>schema:name</td>
        <td>World Financial News</td>
      </tr>
      <tr>
        <td>http://example.com/</td>
        <td>schema:blogPost</td>
        <td>http://example.com/posts/1/en</td>
      </tr>
      <tr>
        <td>http://example.com/</td>
        <td>schema:blogPost</td>
        <td>http://example.com/posts/1/de</td>
      </tr>
      <tr>
        <td>http://example.com/posts/1/en</td>
        <td>schema:articleBody</td>
        <td>World commodities were up today with heavy trading of crude oil...</td>
      </tr>
      <tr>
        <td>http://example.com/posts/1/en</td>
        <td>schema:wordCount</td>
        <td>1539</td>
      </tr>
      <tr>
        <td>http://example.com/posts/1/de</td>
        <td>schema:articleBody</td>
        <td>Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...</td>
      </tr>
      <tr>
        <td>http://example.com/posts/1/de</td>
        <td>schema:wordCount</td>
        <td>1204</td>
      </tr>
    </tbody>
  </table>

  <p class="changed">The value of <code>@container</code> can also
    be an array containing both <code>@index</code> and <code>@set</code>.
    When <em>compacting</em>, this ensures that a <a>JSON-LD Processor</a> will use
    the <a>array</a> form for all values of indexes.</p>

  <pre class="example nohighlight changed" data-transform="updateExample"
       title="Indexing data in JSON-LD with @set representation">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "body": "schema:articleBody",
      "words": "schema:wordCount",
      "post": {
        "@id": "schema:blogPost",
        "@container": ****["@index", "@set"]****
      }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    "post": {
      "en": ****[****{
        "@id": "http://example.com/posts/1/en",
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      }****]****,
      "de": ****[****{
        "@id": "http://example.com/posts/1/de",
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      }****]****
    }
  }
  -->
  </pre>

  <p class="changed">If the <a>processing mode</a> is set to <code>json-ld-1.1</code>,
    the special index <code>@none</code> is used for indexing
    data which does not have an associated index, which is useful to maintain
    a normalized representation.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data using @none">
  <!--
  {
    "@context": {
       "schema": "http://schema.org/",
       "name": "schema:name",
       "body": "schema:articleBody",
       "words": "schema:wordCount",
       "post": {
         "@id": "schema:blogPost",
         ****"@container": "@index"****
       }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    "post": {
      "en": {
        "@id": "http://example.com/posts/1/en",
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      },
      "de": {
        "@id": "http://example.com/posts/1/de",
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      },
      ****"@none": {
        "body": "Unindexed description",
        "words": 20
      }****
    }
  }
  -->
  </pre>
</section>
<section class="changed">
  <h3>Named Graph Indexing</h3>

  <p>In addition to indexing <a>node objects</a> by index, <a>graph objects</a> may
    also be indexed by an index. By using the <code>@graph</code>
    container type, introduced in <a href="#graph-containers" class="sectionRef"></a>
    in addition to <code>@index</code>, an object value of such a property is
    treated as a key-value map where the keys do not map to <a>IRIs</a>, but
    are taken from an <code>@index</code> property associated with <a>named graphs</a>
    which are their values. When expanded, these must be <a>simple graph objects</a></p>

  <p>The following example describes a default graph referencing multiple named
    graphs using an <a>index map</a>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing graph data in JSON-LD">
  <!--
  {
    "@context": {
       ****"@version": 1.1****,
       "schema": "http://schema.org/",
       "name": "schema:name",
       "body": "schema:articleBody",
       "words": "schema:wordCount",
       "post": {
         "@id": "schema:blogPost",
         "@container": ****["@graph"****, "@index"****]****
       }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    ****"post": {
       "en": {
         "@id": "http://example.com/posts/1/en",
         "body": "World commodities were up today with heavy trading of crude oil...",
         "words": 1539
       },
       "de": {
         "@id": "http://example.com/posts/1/de",
         "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
         "words": 1204
       }****
    }
  }
  -->
  </pre>

  <p>This expands to the following:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexed graph data after expansion">
  <!--
  [{
    "@id": "http://example.com/",
    "@type": ["http://schema.org/Blog"],
    "http://schema.org/blogPost": [{
      ****"@graph"****: [{
        "@id": "http://example.com/posts/1/de",
        "http://schema.org/articleBody": [{
          "@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
        }],
        "http://schema.org/wordCount": [{"@value": 1204}]
      }],
      "@index": "de"
    }, {
      ****"@graph"****: [{
        "@id": "http://example.com/posts/1/en",
        "http://schema.org/articleBody": [{
          "@value": "World commodities were up today with heavy trading of crude oil..."
        }],
        "http://schema.org/wordCount": [{"@value": 1539}]
      }],
      "@index": "en"
    }],
    "http://schema.org/name": [{"@value": "World Financial News"}]
  }]
  -->
  </pre>

  <p>When expressed as Quads, this becomes the following:</p>

  <table class="example">
  <thead><tr>
    <th>Graph</th>
    <th>Subject</th>
    <th>Property</th>
    <th>Value</th>
    <th>Value Type</th>
  </tr></thead>
  <tbody>
  <tr>
    <td>&nbsp;</td>
    <td>http://example.com/</td>
    <td>rdf:type</td>
    <td>schema:Blog</td>
    <td></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>http://example.com/</td>
    <td>schema:name</td>
    <td>World Financial News</td>
    <td></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>http://example.com/</td>
    <td>schema:blogPost</td>
    <td>_:b1</td>
    <td></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>http://example.com/</td>
    <td>schema:blogPost</td>
    <td>_:b2</td>
    <td></td>
  </tr>
  <tr>
    <td>_:b1</td>
    <td>http://example.com/posts/1/de</td>
    <td>schema:wordCount</td>
    <td>1204</td>
    <td>xsd:integer</td>
  </tr>
  <tr>
    <td>_:b1</td>
    <td>http://example.com/posts/1/de</td>
    <td>schema:articleBody</td>
    <td>Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...</td>
    <td></td>
  </tr>
  <tr>
    <td>_:b2</td>
    <td>http://example.com/posts/1/en</td>
    <td>schema:wordCount</td>
    <td>1539</td>
    <td>xsd:integer</td>
  </tr>
  <tr>
    <td>_:b2</td>
    <td>http://example.com/posts/1/en</td>
    <td>schema:articleBody</td>
    <td>World commodities were up today with heavy trading of crude oil...</td>
    <td></td>
  </tr>
  </tbody>
  </table>

  <p>As with <a>index maps</a>, when used with <code>@graph</code>, a container may also
    include <code>@set</code> to ensure that key values are always contained in an array.</p>

  <p class="changed">If the <a>processing mode</a> is set to <code>json-ld-1.1</code>,
    the special index <code>@none</code> is used for indexing
    graphs which does not have an <code>@index</code> key, which is useful to maintain
    a normalized representation. <span class="note">Note, however, that
      compacting a document where multiple unidentified named graphs are
      compacted using the <code>@none</code> index will result in the content
      of those graphs being merged. To prevent this, give each graph a distinct
      <code>@index</code> key.</span></p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing graphs using @none for no index">
  <!--
  {
    "@context": {
       "@version": 1.1,
       "schema": "http://schema.org/",
       "name": "schema:name",
       "body": "schema:articleBody",
       "words": "schema:wordCount",
       "post": {
         "@id": "schema:blogPost",
         "@container": ["@graph", "@index"]
       }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    "post": {
       "en": {
         "@id": "http://example.com/posts/1/en",
         "body": "World commodities were up today with heavy trading of crude oil...",
         "words": 1539
       },
       "@none": {
         "@id": "http://example.com/posts/1/de",
         "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
         "words": 1204
       }
    }
  }
  -->
  </pre>

  <p>This expands to the following:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexed languaged-tagged strings with @none after expansion">
  <!--
  [{
    "@id": "http://example.com/",
    "@type": ["http://schema.org/Blog"],
    "http://schema.org/blogPost": [{
      "@graph": [{
        "@id": "http://example.com/posts/1/de",
        "http://schema.org/articleBody": [{
          "@value": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl..."
        }],
        "http://schema.org/wordCount": [{"@value": 1204}]
      }]
    }, {
      "@graph": [{
        "@id": "http://example.com/posts/1/en",
        "http://schema.org/articleBody": [{
          "@value": "World commodities were up today with heavy trading of crude oil..."
        }],
        "http://schema.org/wordCount": [{"@value": 1539}]
      }],
      "@index": "en"
    }],
    "http://schema.org/name": [{"@value": "World Financial News"}]
  }]
  -->
  </pre>
</section>

<section class="informative changed">
  <h2>Language Indexing</h2>

  <p>JSON which includes string values in multiple languages may be
    represented using a <a>language map</a> to allow for easily
    indexing property values by <a>language tag</a>. This enables direct access to
    language values instead of having to scan an array in search of a specific item.
    In JSON-LD such data can be specified by associating the
    <code>@language</code> <a>keyword</a> with a
    <code>@container</code> declaration in the context:</p>

  <pre class="example" data-transform="updateExample"
       title="Indexing languaged-tagged strings in JSON-LD">
  <!--
  {
    "@context": {
      "vocab": "http://example.com/vocab/",
      "label": {
        "@id": "vocab:label",
        "@container": "@language"
      }
    },
    "@id": "http://example.com/queen",
    "label": {
      "en": "The Queen",
      "de": [ "Die Königin", "Ihre Majestät" ]
    }
  }
  -->
  </pre>

  <p>In the example above, the <strong>label</strong> <a>term</a> has
    been marked as an <a>language map</a>. The <strong>en</strong> and
    <strong>de</strong> keys are implicitly associated with their respective
    values by the <a>JSON-LD Processor</a>.  This allows a developer to
    access the German version of the <strong>label</strong> using the
    following code snippet: <code>obj.label.de</code>.</p>

  <p>The value of <code>@container</code> can also
    be an array containing both <code>@language</code> and <code>@set</code>.
    When <em>compacting</em>, this ensures that a <a>JSON-LD Processor</a> will use
    the <a>array</a> form for all values of language tags.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing languaged-tagged strings in JSON-LD with @set representation">
  <!--
  {
    "@context": {
      "vocab": "http://example.com/vocab/",
      "label": {
        "@id": "vocab:label",
        "@container": ****[****"@language", ****"@set"]****
      }
    },
    "@id": "http://example.com/queen",
    "label": {
      "en": ****[****"The Queen"****]****,
      "de": [ "Die Königin", "Ihre Majestät" ]
    }
  }
  -->
  </pre>

  <p class="changed">If the <a>processing mode</a> is set to <code>json-ld-1.1</code>,
    the special index <code>@none</code> is used for indexing
    data which does not have a language, which is useful to maintain
    a normalized representation.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing languaged-tagged strings using @none for no language">
  <!--
  {
    "@context": {
      "vocab": "http://example.com/vocab/",
      "label": {
        "@id": "vocab:label",
        "@container": "@language"
      }
    },
    "@id": "http://example.com/queen",
    "label": {
      "en": "The Queen",
      "de": [ "Die Königin", "Ihre Majestät" ],
      "@none": "The Queen"
    }
  }
  -->
  </pre>
</section>

<section class="informative changed">
  <h2>Node Identifier Indexing</h2>

  <p>In addition to <a>index maps</a>, JSON-LD introduces the notion of <a>id maps</a>
    for structuring data. The id indexing feature allows an author to
    structure data using a simple key-value map where the keys map
    to <a>IRIs</a>. This enables direct access to associated <a>node objects</a>
    instead of having to scan an array in search of a specific item.
    In JSON-LD such data can be specified by associating the
    <code>@id</code> <a>keyword</a> with a
    <code>@container</code> declaration in the context:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by node identifiers">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "body": "schema:articleBody",
      "words": "schema:wordCount",
      "post": {
        "@id": "schema:blogPost",
        ****"@container": "@id"****
      }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    ****"post": {
      "http://example.com/posts/1/en": {
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      },
      "http://example.com/posts/1/de": {
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      }
    }****
  }
  -->
  </pre>

  <p>In the example above, the <code>post</code> <a>term</a> has
    been marked as an <a>id map</a>. The <code>http://example.com/posts/1/en</code> and
    <code>http://example.com/posts/1/de</code> keys will be interpreted
    as the <code>@id</code> property of the <a>node object</a> value.</p>

  <p>The interpretation of the data above is exactly the same
    as that in <a class="sectionRef" href="#data-indexing"></a>
    using a <a>JSON-LD processor</a>.</p>

  <p>The value of <code>@container</code> can also
    be an array containing both <code>@id</code> and <code>@set</code>.
    When <em>compacting</em>, this ensures that a <a>JSON-LD processor</a> will use
    the <a>array</a> form for all values of node identifiers.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by node identifiers with @set representation">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "body": "schema:articleBody",
      "words": "schema:wordCount",
      "post": {
        "@id": "schema:blogPost",
        "@container": ****[****"@id", ****"@set"]****
      }
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    "post": {
      "http://example.com/posts/1/en": ****[****{
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      }****]****,
      "http://example.com/posts/1/de": ****[****{
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      }****]****
    }
  }
  -->
  </pre>

  <p>The special index <code>@none</code> is used for indexing
    <a>node objects</a> which do not have an <code>@id</code>, which is useful to maintain
    a normalized representation. The <code>@none</code> index may also be
    a term which expands to <code>@none</code>, such as the term <em>none</em>
    used in the example below.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by node identifiers using @none">
  <!--
  {
    "@context": {
      "@version": 1.1,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "body": "schema:articleBody",
      "words": "schema:wordCount",
      "post": {
        "@id": "schema:blogPost",
        "@container": "@id"
      },
      ****"none": "@none"****
    },
    "@id": "http://example.com/",
    "@type": "schema:Blog",
    "name": "World Financial News",
    "post": {
      "http://example.com/posts/1/en": {
        "body": "World commodities were up today with heavy trading of crude oil...",
        "words": 1539
      },
      "http://example.com/posts/1/de": {
        "body": "Die Werte an Warenbörsen stiegen im Sog eines starken Handels von Rohöl...",
        "words": 1204
      },
      ****"none": {
        "body": "Description for object within an @id",
        "words": 20
      }****
    }
  }
  -->
  </pre>

  <p class="note"><a>Id maps</a> are a new feature in JSON-LD 1.1, requiring
    <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
</section>

<section class="changed">
  <h3>Named Graph Indexing by Identifier</h3>

  <p>In addition to indexing <a>node objects</a> by identifier, <a>graph objects</a> may
    also be indexed by their <a>graph name</a>. By using the <code>@graph</code>
    container type, introduced in <a href="#graph-containers" class="sectionRef"></a>
    in addition to <code>@id</code>, an object value of such a property is
    treated as a key-value map where the keys represent the identifiers of <a>named graphs</a>
    which are their values.</p>

  <p>The following example describes a default graph referencing multiple named
    graphs using an <a>id map</a>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Referencing named graphs using an id map">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "generatedAt": {
        "@id": "http://www.w3.org/ns/prov#generatedAtTime",
        "@type": "http://www.w3.org/2001/XMLSchema#date"
      },
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "name": "http://xmlns.com/foaf/0.1/name",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      ****"graphMap": {
        "@id": "http://example.org/graphMap",
        "@container": ["@graph", "@id"]
      }****
    },
    "@id": "_:graph",
    "generatedAt": "2012-04-09",
    ****"graphMap": {
      "_:manu":**** {
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "Person",
        "name": "Manu Sporny",
        "knows": "http://greggkellogg.net/foaf#me"
      },
      ****"_:gregg"****: {
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": "Person",
        "name": "Gregg Kellogg",
        "knows": "http://manu.sporny.org/about#manu"
      }
    }
  }
  -->
  </pre>

  <p>This expands to the following:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Referencing named graphs after expansion">
  <!--
  [{
    "@id": "_:graph",
    "http://example.org/graphMap": [{
      "@id": "_:gregg",
      "@graph": [{
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": ["http://xmlns.com/foaf/0.1/Person"],
        "http://xmlns.com/foaf/0.1/knows": [{"@value": "http://manu.sporny.org/about#manu"}],
        "http://xmlns.com/foaf/0.1/name": [{"@value": "Gregg Kellogg"}]
      }]
    }, {
      "@id": "_:manu",
      "@graph": [{
        "@id": "http://manu.sporny.org/about#manu",
        "@type": [
          "http://xmlns.com/foaf/0.1/Person"
        ],
        "http://xmlns.com/foaf/0.1/knows": [
          {
            "@value": "http://greggkellogg.net/foaf#me"
          }
        ],
        "http://xmlns.com/foaf/0.1/name": [
          {
            "@value": "Manu Sporny"
          }
        ]
      }]
    }],
    "http://www.w3.org/ns/prov#generatedAtTime": [{
      "@value": "2012-04-09",
      "@type": "http://www.w3.org/2001/XMLSchema#date"
    }]
  }]
  -->
  </pre>

  <p>When expressed as Quads, this becomes the following:</p>

  <table class="example">
  <thead><tr>
    <th>Graph</th>
    <th>Subject</th>
    <th>Property</th>
    <th>Value</th>
    <th>Value Type</th>
  </tr></thead>
  <tbody>
  <tr>
    <td>&nbsp;</td>
    <td>_:graph</td>
    <td>prov:generatedAtTime</td>
    <td>2012-04-09</td>
    <td>xsd:date</td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>_:graph</td>
    <td>http://example.org/graphMap</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td></td>
  </tr>
  <tr>
    <td>&nbsp;</td>
    <td>_:graph</td>
    <td>http://example.org/graphMap</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td></td>
  </tr>
  <tr>
    <td>_:manu</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>xsd:type</td>
    <td>foaf:Person</td>
    <td></td>
  </tr>
  <tr>
    <td>_:manu</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>foaf:name</td>
    <td>Manu Sporny</td>
    <td></td>
  </tr>
  <tr>
    <td>_:manu</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td>foaf:knows</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td></td>
  </tr>
  <tr>
    <td>_:gregg</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>xsd:type</td>
    <td>foaf:Person</td>
    <td></td>
  </tr>
  <tr>
    <td>_:gregg</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>foaf:name</td>
    <td>Gregg Kellogg</td>
    <td></td>
  </tr>
  <tr>
    <td>_:gregg</td>
    <td>http://greggkellogg.net/foaf#me</td>
    <td>foaf:knows</td>
    <td>http://manu.sporny.org/about#manu</td>
    <td></td>
  </tr>
  </tbody>
  </table>

  <p>As with <a>id maps</a>, when used with <code>@graph</code>, a container may also
    include <code>@set</code> to ensure that key values are always contained in an array.</p>

  <p>As with <a>id maps</a>, the special index <code>@none</code> is used for indexing
    <a>named graphs</a> which do not have an <code>@id</code>, which is useful to maintain
    a normalized representation. The <code>@none</code> index may also be
    a term which expands to <code>@none</code>.
    <span class="note">Note, however, that if multiple graphs are represented without
      an <code>@id</code>, they will be merged on expansion. To prevent this,
      use <code>@none</code> judiciously, and consider giving graphs
      their own distinct identifier.</span></p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Referencing named graphs using an id map with @none">
  <!--
  {
    "@context": {
      "@version": 1.1,
      "generatedAt": {
        "@id": "http://www.w3.org/ns/prov#generatedAtTime",
        "@type": "http://www.w3.org/2001/XMLSchema#date"
      },
      "Person": "http://xmlns.com/foaf/0.1/Person",
      "name": "http://xmlns.com/foaf/0.1/name",
      "knows": "http://xmlns.com/foaf/0.1/knows",
      "graphMap": {
        "@id": "http://example.org/graphMap",
        "@container": ["@graph", "@id"]
      }
    },
    "@id": "_:graph",
    "generatedAt": "2012-04-09",
    "graphMap": {
      ****"@none"****: [{
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "Person",
        "name": "Manu Sporny",
        "knows": "http://greggkellogg.net/foaf#me"
      }, {
        "@id": "http://greggkellogg.net/foaf#me",
        "@type": "Person",
        "name": "Gregg Kellogg",
        "knows": "http://manu.sporny.org/about#manu"
      }]
    }
  }
  -->
  </pre>

  <p class="note">Graph Containers are a new feature in JSON-LD 1.1, requiring
    <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
</section>

<section class="informative changed">
  <h2>Node Type Indexing</h2>

  <p>In addition to <a data-lt="id map">id</a> and <a>index maps</a>, JSON-LD introduces the notion of <a>type maps</a>
    for structuring data. The type indexing feature allows an author to
    structure data using a simple key-value map where the keys map
    to <a>IRIs</a>. This enables data to be structured based on the <code>@type</code>
    of specific <a>node objects</a>.
    In JSON-LD such data can be specified by associating the
    <code>@type</code> <a>keyword</a> with a
    <code>@container</code> declaration in the context:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by type">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "affiliation": {
        "@id": "schema:affiliation",
        ****"@container": "@type"****
      }
    },
    "name": "Manu Sporny",
    "affiliation": {
      ****"schema:Corporation"****: {
        "@id": "https://digitalbazaar.com/",
        "name": "Digital Bazaar"
      },
      ****"schema:ProfessionalService"****: {
        "@id": "https://spec-ops.io",
        "name": "Spec-Ops"
      }
    }
  }
  -->
  </pre>

  <p>In the example above, the <code>affiliation</code> <a>term</a> has
    been marked as an <a>type map</a>. The <code>schema:Corporation</code> and
    <code>schema:ProfessionalService</code> keys will be interpreted
    as the <code>@type</code> property of the <a>node object</a> value.</p>

  <p>The value of <code>@container</code> can also
    be an array containing both <code>@type</code> and <code>@set</code>.
    When <em>compacting</em>, this ensures that a <a>JSON-LD processor</a> will use
    the <a>array</a> form for all values of types.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by type with @set representation">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "affiliation": {
        "@id": "schema:affiliation",
        "@container": ****[****"@type", ****"@set"]****
      }
    },
    "name": "Manu Sporny",
    "affiliation": {
      "schema:Corporation": ****[****{
        "@id": "https://digitalbazaar.com/",
        "name": "Digital Bazaar"
      }****]****,
      "schema:ProfessionalService": ****[****{
        "@id": "https://spec-ops.io",
        "name": "Spec-Ops"
      }****]****
    }
  }
  -->
  </pre>

  <p>The special index <code>@none</code> is used for indexing
    <a>node objects</a> which do not have an <code>@type</code>, which is useful to maintain
    a normalized representation. The <code>@none</code> index may also be
    a term which expands to <code>@none</code>, such as the term <em>none</em>
    used in the example below.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Indexing data in JSON-LD by type using @none">
  <!--
  {
    "@context": {
      "@version": 1.1,
      "schema": "http://schema.org/",
      "name": "schema:name",
      "affiliation": {
        "@id": "schema:affiliation",
        "@container": "@type"
      },
      ****"none": "@none"****
    },
    "name": "Manu Sporny",
    "affiliation": {
      "schema:Corporation": {
        "@id": "https://digitalbazaar.com/",
        "name": "Digital Bazaar"
      },
      "schema:ProfessionalService": {
        "@id": "https://spec-ops.io",
        "name": "Spec-Ops"
      },
      ****"none": {
        "@id": "http://greggkellogg.net/",
        "name": "Gregg Kellogg"
      }****
    }
  }
  -->
  </pre>

  <p>As with <a>id maps</a>, when used with <code>@type</code>, a container may also
    include <code>@set</code> to ensure that key values are always contained in an array.</p>

  <p class="note"><a>Type maps</a> are a new feature in JSON-LD 1.1, requiring
    <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
</section>

<section class="informative changed">
  <h2>Nested Properties</h2>

  <p>Many JSON APIs separate properties from their entities using an
    intermediate object; in JSON-LD these are called <a>nested properties</a>.
    For example, a set of possible labels may be grouped
    under a common property:</p>
  <pre class="example nohighlight" data-transform="updateExample"
       title="Nested properties">
  <!--
  {
    "@context": {
      ****"@version": 1.1****,
      "skos": "http://www.w3.org/2004/02/skos/core#",
      ****"labels": "@nest"****,
      "main_label": {"@id": "skos:prefLabel"},
      "other_label": {"@id": "skos:altLabel"},
      "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
    },
    "@id": "http://example.org/myresource",
    "homepage": "http://example.org",
    "labels": {
       "main_label": "This is the main label for my resource",
       "other_label": "This is the other label"
    }
  }
  -->
  </pre>

  <p>By defining <em>labels</em> using the <a>keyword</a> <code>@nest</code>,
    a <a>JSON-LD processor</a> will ignore the nesting created by using the
    <em>labels</em> property and process the contents as if it were declared
    directly within containing object. In this case, the <em>labels</em>
    property is semantically meaningless. Defining it as equivalent to
    <code>@nest</code> causes it to be ignored when expanding, making it
    equivalent to the following:</p>

  <pre class="example nohighlight" data-transform="updateExample"
       title="Nested properties folded into containing object">
  <!--
  {
    "@context": {
      "skos": "http://www.w3.org/2004/02/skos/core#",
      "main_label": {"@id": "skos:prefLabel"},
      "other_label": {"@id": "skos:altLabel"},
      "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
    },
    "@id": "http://example.org/myresource",
    "homepage": "http://example.org",
    ****"main_label": "This is the main label for my resource",
    "other_label": "This is the other label"****
  }
  -->
  </pre>

  <p>Similarly, node definitions may contain a <code>@nest</code> property to
    reference a term aliased to <code>@nest</code> which causes such
    values to be nested under that aliased term.</p>
  <pre class="example nohighlight" data-transform="updateExample"
       title="Defining property nesting">
  <!--
 {
   "@context": {
     ****"@version": 1.1****,
     "skos": "http://www.w3.org/2004/02/skos/core#",
     ****"labels": "@nest"****,
     "main_label": {"@id": "skos:prefLabel", ****"@nest": "labels"****},
     "other_label": {"@id": "skos:altLabel", ****"@nest": "labels"****},
     "homepage": {"@id": "http://schema.org/description", "@type": "@id"}
   },
   "@id": "http://example.org/myresource",
   "homepage": "http://example.org",
   "labels": {
      "main_label": "This is the main label for my resource",
      "other_label": "This is the other label"
   }
 }
  -->
  </pre>

  <p class="note"><a>Nested properties</a> are a new feature in JSON-LD 1.1, requiring
    <a>processing mode</a> set to <code>json-ld-1.1</code>.</p>
</section>

<section class="informative">
  <h3>Expanded Document Form</h3>

  <p>The JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]]
    defines a method for <em>expanding</em> a JSON-LD document.
    <dfn data-cite="JSON-LD11CG-API#dfn-expansion">Expansion</dfn> is the process of taking a JSON-LD document and applying a
    <code>@context</code> such that all IRIs, types, and values
    are expanded so that the <code>@context</code> is no longer necessary.</p>

  <p>For example, assume the following JSON-LD input document:</p>

  <pre class="example" data-transform="updateExample"
       title="Sample JSON-LD document to be expanded">
  <!--
  {
     "@context": {
        "name": "http://xmlns.com/foaf/0.1/name",
        "homepage": {
          "@id": "http://xmlns.com/foaf/0.1/homepage",
          "@type": "@id"
        }
     },
     "name": "Manu Sporny",
     "homepage": "http://manu.sporny.org/"
  }
  -->
  </pre>

  <p>Running the JSON-LD <a data-cite="JSON-LD11CG-API#expansion-algorithm">Expansion algorithm</a> against the JSON-LD input document
    provided above would result in the following output:</p>

  <pre class="example" data-transform="updateExample"
       title="Expanded form for the previous example">
  <!--
  [
    {
      "http://xmlns.com/foaf/0.1/name": [
        { "@value": "Manu Sporny" }
      ],
      "http://xmlns.com/foaf/0.1/homepage": [
        { "@id": "http://manu.sporny.org/" }
      ]
    }
  ]
  -->
  </pre>

  <p><a href="#application-ld-json">JSON-LD's media type</a> defines a
    <code>profile</code> parameter which can be used to signal or request
    expanded document form. The profile URI identifying expanded document
    form is <code>http://www.w3.org/ns/json-ld#expanded</code>.</p>
</section>

<section class="informative">
  <h3>Compacted Document Form</h3>

  <p>The JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]] defines
    a method for <em>compacting</em> a JSON-LD document. <dfn data-cite="JSON-LD11CG-API#dfn-compaction">Compaction</dfn> is the process
    of applying a developer-supplied context to shorten <a>IRIs</a>
    to <a>terms</a> or <a>compact IRIs</a>
    and JSON-LD values expressed in expanded form to simple values such as
    <a>strings</a> or <a>numbers</a>.
    Often this makes it simpler to work with document as the data is expressed in
    application-specific terms. Compacted documents are also typically easier to read
    for humans.</p>

  <p>For example, assume the following JSON-LD input document:</p>

  <pre class="example" data-transform="updateExample"
       title="Sample expanded JSON-LD document">
  <!--
  [
    {
      "http://xmlns.com/foaf/0.1/name": [ "Manu Sporny" ],
      "http://xmlns.com/foaf/0.1/homepage": [
        {
         "@id": "http://manu.sporny.org/"
        }
      ]
    }
  ]
  -->
  </pre>

  <p>Additionally, assume the following developer-supplied JSON-LD context:</p>

  <pre class="example" data-transform="updateExample"
       title="Sample context">
  <!--
  {
    "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type": "@id"
      }
    }
  }
  -->
  </pre>

  <p>Running the JSON-LD <a data-cite="JSON-LD11CG-API#compaction-algorithm">Compaction algorithm</a> given the context supplied above
    against the JSON-LD input document provided above would result in the following
    output:</p>

  <pre class="example" data-transform="updateExample"
       title="Compact form of the sample document once sample context has been applied">
  <!--
  {
    "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": {
        "@id": "http://xmlns.com/foaf/0.1/homepage",
        "@type": "@id"
      }
    },
    "name": "Manu Sporny",
    "homepage": "http://manu.sporny.org/"
  }
  -->
  </pre>

  <p><a href="#application-ld-json">JSON-LD's media type</a> defines a
    <code>profile</code> parameter which can be used to signal or request
    compacted document form. The profile URI identifying compacted document
    form is <code>http://www.w3.org/ns/json-ld#compacted</code>.</p>
</section>

<section class="informative">
  <h3>Flattened Document Form</h3>

  <p>The JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]] defines
    a method for <em>flattening</em> a JSON-LD document. <dfn data-cite="JSON-LD11CG-API#dfn-flattening">Flattening</dfn> collects all
    properties of a <a>node</a> in a single <a>JSON object</a> and labels
    all <a>blank nodes</a> with
    <a>blank node identifiers</a>.
    This ensures a shape of the data and consequently may drastically simplify the code
    required to process JSON-LD in certain applications.</p>

  <p>For example, assume the following JSON-LD input document:</p>

  <pre class="example" data-transform="updateExample"
       title="Sample JSON-LD document to be flattened">
  <!--
  {
    "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "knows": "http://xmlns.com/foaf/0.1/knows"
    },
    "@id": "http://me.markus-lanthaler.com/",
    "name": "Markus Lanthaler",
    "knows": [
      {
        "@id": "http://manu.sporny.org/about#manu",
        "name": "Manu Sporny"
      }, {
        "name": "Dave Longley"
      }
    ]
  }
  -->
  </pre>

  <p>Running the JSON-LD <a data-cite="JSON-LD11CG-API#flattening-algorithm">Flattening algorithm</a> against the JSON-LD input document in
    the example above and using the same context would result in the following
    output:</p>

  <pre class="example" data-transform="updateExample"
       title="Flattened and compacted form for the previous example">
  <!--
  {
    "@context": {
      "name": "http://xmlns.com/foaf/0.1/name",
      "knows": "http://xmlns.com/foaf/0.1/knows"
    },
    "@graph": [
      {
        "@id": "_:b0",
        "name": "Dave Longley"
      }, {
        "@id": "http://manu.sporny.org/about#manu",
        "name": "Manu Sporny"
      }, {
        "@id": "http://me.markus-lanthaler.com/",
        "name": "Markus Lanthaler",
        "knows": [
          { "@id": "http://manu.sporny.org/about#manu" },
          { "@id": "_:b0" }
        ]
      }
    ]
  }
  -->
  </pre>

  <p><a href="#application-ld-json">JSON-LD's media type</a> defines a
    <code>profile</code> parameter which can be used to signal or request
    flattened document form. The profile URI identifying flattened document
    form is <code>http://www.w3.org/ns/json-ld#flattened</code>. It can be
    combined with the profile URI identifying
    <a href="#expanded-document-form">expanded document form</a> or
    <a href="#compacted-document-form">compacted document from</a>.</p>
</section>

<section class="informative">
  <h2>Embedding JSON-LD in HTML Documents</h2>

  <p>HTML script tags can be used to embed blocks of data in documents.
    This way, JSON-LD content can be easily embedded in HTML by placing
    it in a script element with the <code>type</code> attribute set to
    <code>application/ld+json</code>.</p>

  <pre class="example nohighlight" data-transform="updateExample"
       data-content-type="text/html"
       title="Embedding JSON-LD in HTML">
  <!--
  ****<script type="application/ld+json">****
  {
    "@context": "https://json-ld.org/contexts/person.jsonld",
    "@id": "http://dbpedia.org/resource/John_Lennon",
    "name": "John Lennon",
    "born": "1940-10-09",
    "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
  }
  ****</script>****
  -->
  </pre>

  <p>Depending on how the HTML document is served, certain strings may need
    to be escaped.</p>

  <p>Defining how such data may be used is beyond the scope of this specification.
    The embedded JSON-LD document might be extracted as is or, e.g., be
    interpreted as RDF.</p>

  <p>If JSON-LD content is extracted as RDF [[RDF11-CONCEPTS]], it should be expanded into an
    <a>RDF Dataset</a> using the
    <a data-cite="JSON-LD11CG-API#deserialize-json-ld-to-rdf-algorithm">Deserialize JSON-LD to RDF Algorithm</a>
    [[JSON-LD11CG-API]].</p>
</section>

</section>

<section class="normative">
  <h1>Data Model</h1>

  <p>JSON-LD is a serialization format for Linked Data based on JSON.
    It is therefore important to distinguish between the syntax, which is
    defined by JSON in [[!RFC7159]], and the <dfn>data model</dfn> which is
    an extension of the <a data-cite="RDF11-CONCEPTS#data-model">RDF data model</a> [[!RDF11-CONCEPTS]]. The precise
    details of how JSON-LD relates to the RDF data model are given in
    <a class="sectionRef" href="#relationship-to-rdf"></a>.</p>

  <p>To ease understanding for developers unfamiliar with the RDF model, the
    following summary is provided:</p>

  <ul>
    <li>A <a>JSON-LD document</a> serializes a
      <a>generalized RDF Dataset</a>
      [[!RDF11-CONCEPTS]], which is a collection of <a>graphs</a>
      that comprises exactly one <a>default graph</a>
      and zero or more <a>named graphs</a>.</li>
    <li>The <a>default graph</a> does not have a name and MAY be empty.</li>
    <li>Each <a>named graph</a> is a pair consisting of an <a>IRI</a> or
      <a>blank node identifier</a> (the
      <a>graph name</a>)
      and a <a>graph</a>. Whenever practical, the <a>graph name</a> SHOULD be an <a>IRI</a>.</li>
    <li>A <a>graph</a>
      is a labeled directed graph, i.e., a set of <a>nodes</a>
      connected by <a>edges</a>.</li>
    <li>Every <a>edge</a> has a direction associated with it and is labeled with
      an <a>IRI</a> or a <a>blank node identifier</a>. Within the JSON-LD syntax
      these edge labels are called <a>properties</a>.
      Whenever practical, an <a>edge</a> SHOULD be labeled with an <a>IRI</a>.</li>
    <li>Every <a>node</a>
      is an <a>IRI</a>, a <a>blank node</a>, a <a>JSON-LD value</a>,
      or a <a>list</a>.</li>
    <li>A <a>node</a> having an outgoing edge MUST be an <a>IRI</a> or a
      <a>blank node</a>.</li>
    <li>A <a>graph</a> MUST NOT contain unconnected <a>nodes</a>,
      i.e., nodes which are not connected by an <a>edge</a> to any other <a>node</a>.
      <pre class="illegal-example"
          data-transform="updateExample"
          title="Illegal Unconnected Node">
      <!--
      {
        "@id": "http://example.org/1"
      }
      -->
      </pre>
      <div class="note">
        This effectively just prohibits unnested, empty <a>node objects</a>
        and unnested <a>node objects</a> that contain only an <code>@id</code>.
        A document may have <a>nodes</a> which are unrelated, as long as one or more
        properties are defined, or the <a>node</a> is referenced from another <a>node object</a>.
      </div>
    </li>
    <li>An <a>IRI</a> (Internationalized Resource Identifier) is a string that conforms to the syntax
      defined in [[RFC3987]]. <a>IRIs</a> used within a
      <a>graph</a> SHOULD return a Linked Data document describing
      the resource denoted by that <a>IRI</a> when being dereferenced.</li>
    <li>A <a>blank node</a> is a <a>node</a> which is neither an <a>IRI</a>,
      nor a <a>JSON-LD value</a>, nor a <a>list</a>. A blank node MAY be identified
      using a <a>blank node identifier</a>.</li>
    <li>A <a>blank node identifier</a>
      is a string that can be used as an identifier for a <a>blank node</a> within
      the scope of a <a>JSON-LD document</a>. Blank node identifiers begin with
      <code>_:</code>.</li>
    <li>A <a>JSON-LD value</a> is a <a>typed value</a>, a <a>string</a> (which is interpreted
      as <a>typed value</a> with type <code>xsd:string</code>), a <a>number</a>
      (<a>numbers</a> with a non-zero fractional part, i.e., the result of a modulo&#8209;1 operation,
      are interpreted as <a>typed values</a> with type <code>xsd:double</code>, all other
      <a>numbers</a> are interpreted as <a>typed values</a>
      with type <code>xsd:integer</code>), <a>true</a> or <a>false</a> (which are interpreted as
      <a>typed values</a> with type <code>xsd:boolean</code>),
      or a <a>language-tagged string</a>.</li>
    <li>A <a>typed value</a> consists of a value, which is a string, and a type, which is an
      <a>IRI</a>.</li>
    <li>A <a>language-tagged string</a>
      consists of a string and a non-empty <a>language tag</a> as defined by [[BCP47]].
      The language tag MUST be well-formed according to section
      <a data-cite="BCP47#section-2.2.9">2.2.9 Classes of Conformance</a>
      of [[BCP47]].</li>
    <li>A <a>list</a> is a sequence of zero or more <a>IRIs</a>,
      <a>blank nodes</a>, and <a>JSON-LD values</a>.
      <a>Lists</a> are interpreted as
      <dfn data-cite="RDF11-MT#rdf-collections">RDF list structures</dfn> [[RDF11-MT]].</li>
  </ul>

  <p><a>JSON-LD documents</a> MAY contain data
    that cannot be represented by the <a>data model</a>
    defined above. Unless otherwise specified, such data is ignored when a
    <a>JSON-LD document</a> is being processed. One result of this rule
    is that properties which are not mapped to an <a>IRI</a>,
    a <a>blank node</a>, or <a>keyword</a> will be ignored.</p>

  <p class="changed">Additionally, the JSON serialization format is internally represented using
    the <a>JSON-LD internal representation</a>, which uses the generic
    concepts of <a>arrays</a>, <a>dictionaries</a>,
    <a>strings</a>, <a>numbers</a>, <a>booleans</a>, and <a>null</a> to describe
    the data represented by a JSON document.</p>
  <p style="text-align: center"><img src="linked-data-graph.png" title="An illustration of the data model" alt="An illustration of the data model" /></p>
  <p style="text-align: center">Figure&nbsp;1: An illustration of the data model.</p>
</section>

<section class="normative">
  <h1>JSON-LD Grammar</h1>

  <p>This appendix restates the syntactic conventions described in the
    previous sections more formally.</p>

  <p>A <a>JSON-LD document</a> MUST be valid <a data-cite="RFC7159#section-2">JSON text</a> as described
    in [[!RFC7159]], <span class="changed">or some format that can be represented
      in the <a>JSON-LD internal representation</a> that is equivalent to
      valid <a data-cite="RFC7159#section-2">JSON text</a></span>.</p>

  <p>A <a>JSON-LD document</a> MUST be a single <a>node object</a>,
    a <a>JSON object</a> consisting of only
    the members <code>@context</code> and/or <code>@graph</code>,
    or an <a>array</a> or zero or more <a>node objects</a>.</p>

  <p>In contrast to JSON, in JSON-LD the keys in <a data-lt="JSON object">objects</a>
    MUST be unique.</p>

  <p class="note">JSON-LD allows <a>keywords</a> to be aliased
    (see <a class="sectionRef" href="#aliasing-keywords"></a> for details). Whenever a <a>keyword</a> is
    discussed in this grammar, the statements also apply to an alias for
    that <a>keyword</a>. For example, if the <a>active context</a>
    defines the <a>term</a> <code>id</code> as an alias for <code>@id</code>,
    that alias may be legitimately used as a substitution for <code>@id</code>.
    Note that <a>keyword</a> aliases are not expanded during context
    processing.</p>

  <section class="normative">
    <h2>Terms</h2>

    <p>A <a>term</a> is a short-hand <a>string</a> that expands
      to an <a>IRI</a> or a <a>blank node identifier</a>.</p>

    <p>A <a>term</a> MUST NOT equal any of the JSON-LD
      <a>keywords</a>.</p>

    <p class="changed">When used as the <a>prefix</a> in a <a>Compact IRI</a>, to avoid
      the potential ambiguity of a <a>prefix</a> being confused with an IRI
      scheme, <a>terms</a> SHOULD NOT come from the list of URI schemes as defined in
      [[!IANA-URI-SCHEMES]]. Similarly, to avoid confusion between a
      <a>Compact IRI</a> and a <a>term</a>, terms SHOULD NOT include a colon (<code>:</code>)
      and SHOULD be restricted to the form of
      <code><a data-cite="RFC3987#section-2.2">isegment-nz-nc</a></code>
      as defined in [[!RFC3987]].</p>

    <p>To avoid forward-compatibility issues, a <a>term</a> SHOULD NOT start
      with an <code>@</code> character as future versions of JSON-LD may introduce
      additional <a>keywords</a>. Furthermore, the term MUST NOT
      be an empty <a>string</a> (<code>""</code>) as not all programming languages
      are able to handle empty JSON keys.</p>

    <p>See <a class="sectionRef" href="#the-context"></a> and
      <a class="sectionRef" href="#iris"></a> for further discussion
      on mapping <a>terms</a> to <a>IRIs</a>.</p>
  </section>

  <section class="normative">
    <h2>Node Objects</h2>

    <p>A <a>node object</a> represents zero or more properties of a
      <a>node</a> in the <a>graph</a> serialized by the
      <a>JSON-LD document</a>. A <a>JSON object</a> is a
      <a>node object</a> if it exists outside of a JSON-LD
      <a>context</a> and:</p>

    <ul>
      <li>it is not the top-most <a>JSON object</a> in the JSON-LD document consisting
        of no other members than <code>@graph</code> and <code>@context</code>,</li>
      <li>it does not contain the <code>@value</code>, <code>@list</code>,
        or <code>@set</code> keywords, and</li>
      <li class="changed">it is not a <a>graph object</a>.</li>
    </ul>

    <p>The <a>properties</a> of a <a>node</a> in
      a <a>graph</a> may be spread among different
      <a>node objects</a> within a document. When
      that happens, the keys of the different
      <a>node objects</a> need to be merged to create the
      properties of the resulting <a>node</a>.</p>

    <p>A <a>node object</a> MUST be a <a>JSON object</a>. All keys
      which are not <a>IRIs</a>, <a>compact IRIs</a>, <a>terms</a> valid in the
      <a>active context</a>, or one of the following <a>keywords</a>
      <span class="changed">(or alias of such a keyword)</span>
      MUST be ignored when processed:</p>

    <ul>
      <li><code>@context</code>,</li>
      <li><code>@id</code>,</li>
      <li><code>@graph</code>,</li>
      <li class="changed"><code>@nest</code>,</li>
      <li><code>@type</code>,</li>
      <li><code>@reverse</code>, or</li>
      <li><code>@index</code></li>
    </ul>

    <p>If the <a>node object</a> contains the <code>@context</code>
      key, its value MUST be <a>null</a>, an <a>absolute IRI</a>,
      a <a>relative IRI</a>, a <a>context definition</a>, or
      an <a>array</a> composed of any of these.</p>

    <p>If the <a>node object</a> contains the <code>@id</code> key,
      its value MUST be an <a>absolute IRI</a>, a <a>relative IRI</a>,
      or a <a>compact IRI</a> (including
      <a>blank node identifiers</a>).
      See <a class="sectionRef" href="#node-identifiers"></a>,
      <a class="sectionRef" href="#compact-iris"></a>, and
      <a class="sectionRef" href="#identifying-blank-nodes"></a> for further discussion on
      <code>@id</code> values.</p>

    <p>If the <a>node object</a> contains the <code>@graph</code>
      key, its value MUST be
      a <a>node object</a> or
      an <a>array</a> of zero or more <a>node objects</a>.
      If the <a>node object</a> contains an <code>@id</code> keyword,
      its value is used as the <a>graph name</a> of a <a>named graph</a>.
      See <a class="sectionRef" href="#named-graphs"></a> for further discussion on
      <code>@graph</code> values. As a special case, if a <a>JSON object</a>
      contains no keys other than <code>@graph</code> and <code>@context</code>, and the
      <a>JSON object</a> is the root of the JSON-LD document, the
      <a>JSON object</a> is not treated as a <a>node object</a>; this
      is used as a way of defining <a>node objects</a>
      that may not form a connected graph. This allows a
      <a>context</a> to be defined which is shared by all of the constituent
      <a>node objects</a>.</p>

    <p>If the <a>node object</a> contains the <code>@type</code>
      key, its value MUST be either an <a>absolute IRI</a>, a
      <a>relative IRI</a>, a <a>compact IRI</a>
      (including <a>blank node identifiers</a>),
      a <a>term</a> defined in the <a>active context</a> expanding into an <a>absolute IRI</a>, or
      an <a>array</a> of any of these.
      See <a class="sectionRef" href="#specifying-the-type"></a> for further discussion on
      <code>@type</code> values.</p>

    <p>If the <a>node object</a> contains the <code>@reverse</code> key,
      its value MUST be a <a>JSON object</a> containing members representing reverse
      properties. Each value of such a reverse property MUST be an <a>absolute IRI</a>,
      a <a>relative IRI</a>, a <a>compact IRI</a>, a <a>blank node identifier</a>,
      a <a>node object</a> or an <a>array</a> containing a combination of these.</p>

    <p>If the <a>node object</a> contains the <code>@index</code> key,
      its value MUST be a <a>string</a>. See
      <a class="sectionRef" href="#data-indexing"></a> for further discussion
      on <code>@index</code> values.</p>

    <p class="changed">If the <a>node object</a> contains the <code>@nest</code> key,
      its value MUST be an <a>JSON object</a> or an <a>array</a> of <a>JSON objects</a>
      which MUST NOT include a <a>value object</a>. See
      <a class="sectionRef" href="#property-nesting"></a> for further discussion
      on <code>@nest</code> values.</p>

    <p>Keys in a <a>node object</a> that are not
      <a>keywords</a> MAY expand to an <a>absolute IRI</a>
      using the <a>active context</a>. The values associated with keys that expand
      to an <a>absolute IRI</a> MUST be one of the following:</p>

    <ul>
      <li><a>string</a>,</li>
      <li><a>number</a>,</li>
      <li><a>true</a>,</li>
      <li><a>false</a>,</li>
      <li><a>null</a>,</li>
      <li><a>node object</a>,</li>
      <li class="changed"><a>graph object</a>,</li>
      <li><a>value object</a>,</li>
      <li><a>list object</a>,</li>
      <li><a>set object</a>,</li>
      <li>an <a>array</a> of zero or more of any of the possibilities above,</li>
      <li>a <a>language map</a>,</li>
      <li>an <a>index map</a>,</li>
      <li class="changed">an <a>id map</a>, or</li>
      <li class="changed">an <a>type map</a></li>
    </ul>
  </section>

  <section class="normative">
    <h2>Graph Objects</h2>

    <p>A <a>graph object</a> represents a <a>named graph</a>, which MAY include
      include an explicit <a>graph name</a>.
      A <a>JSON object</a> is a <a>graph object</a> if
      it exists outside of a JSON-LD <a>context</a>,
      it is not a <a>node object</a>,
      it is not the top-most <a>JSON object</a> in the JSON-LD document, and
      it consists of no members other than <code>@graph</code>,
      <code>@index</code>, <code>@id</code>
      and <code>@context</code>, or an alias of one of these <a>keywords</a>.</p>

    <p>If the <a>graph object</a> contains the <code>@context</code>
      key, its value MUST be <a>null</a>, an <a>absolute IRI</a>,
      a <a>relative IRI</a>, a <a>context definition</a>, or
      an <a>array</a> composed of any of these.</p>

    <p>If the <a>graph object</a> contains the <code>@id</code> key,
      its value is used as the identifier (<a>graph name</a>) of a <a>named graph</a>, and
      MUST be an <a>absolute IRI</a>, a <a>relative IRI</a>,
      or a <a>compact IRI</a> (including
      <a>blank node identifiers</a>).
      See <a class="sectionRef" href="#node-identifiers"></a>,
      <a class="sectionRef" href="#compact-iris"></a>, and
      <a class="sectionRef" href="#identifying-blank-nodes"></a> for further discussion on
      <code>@id</code> values.</p>

    <p>A <a>graph object</a> without an <code>@id</code> member is also a
      <a>simple graph object</a> and represents a <a>named graph</a> without an
      explicit identifier, although in the data model it still has a
      <a>graph name</a>, which is an implicitly allocated
      <a>blank node identifier</a>.</p>

    <p>The value of the <code>@graph</code> key MUST be
      a <a>node object</a> or
      an <a>array</a> of zero or more <a>node objects</a>.
      See <a class="sectionRef" href="#named-graphs"></a> for further discussion on
      <code>@graph</code> values..</p>
  </section>

  <section class="normative">
    <h2>Value Objects</h2>

    <p>A <a>value object</a> is used to explicitly associate a type or a
      language with a value to create a <a>typed value</a> or a <a>language-tagged
      string</a>.</p>

    <p>A <a>value object</a> MUST be a <a>JSON object</a> containing the
      <code>@value</code> key. It MAY also contain an <code>@type</code>,
      an <code>@language</code>, an <code>@index</code>, or an <code>@context</code> key but MUST NOT contain
      both an <code>@type</code> and an <code>@language</code> key at the same time.
      A <a>value object</a> MUST NOT contain any other keys that expand to an
      <a>absolute IRI</a> or <a>keyword</a>.</p>

    <p>The value associated with the <code>@value</code> key MUST be either a
      <a>string</a>, a <a>number</a>, <a>true</a>,
      <a>false</a> or <a>null</a>.</p>

    <p>The value associated with the <code>@type</code> key MUST be a
      <a>term</a>, a <a>compact IRI</a>,
      an <a>absolute IRI</a>, a string which can be turned
      into an <a>absolute IRI</a> using the <a>vocabulary mapping</a>, or <a>null</a>.</p>

    <p>The value associated with the <code>@language</code> key MUST have the
      <a data-cite="BCP47#section-2.1.1">lexical form</a> described in [[!BCP47]], or be <a>null</a>.</p>

    <p>The value associated with the <code>@index</code> key MUST be a
      <a>string</a>.</p>

    <p>See <a class="sectionRef" href="#typed-values"></a> and
      <a class="sectionRef" href="#string-internationalization"></a>
      for more information on <a>value objects</a>.</p>
  </section>

  <section class="normative">
    <h2>Lists and Sets</h2>

    <p>A <a>list</a> represents an <em>ordered</em> set of values. A set
      represents an <em>unordered</em> set of values. Unless otherwise specified,
      <a>arrays</a> are unordered in JSON-LD. As such, the
      <code>@set</code> keyword, when used in the body of a JSON-LD document,
      represents just syntactic sugar which is optimized away when processing the document.
      However, it is very helpful when used within the context of a document. Values
      of terms associated with an <code>@set</code> or <code>@list</code> container
      will always be represented in the form of an <a>array</a> when a document
      is processed&mdash;even if there is just a single value that would otherwise be optimized to
      a non-array form in <a href="#compacted-document-form">compact document form</a>.
      This simplifies post-processing of the data as the data is always in a
      deterministic form.</p>

    <p>A <a>list object</a> MUST be a <a>JSON object</a> that contains no
      keys that expand to an <a>absolute IRI</a> or <a>keyword</a> other
      than <code>@list</code>, <code>@context</code>, and <code>@index</code>.</p>

    <p>A <a>set object</a> MUST be a <a>JSON object</a> that contains no
      keys that expand to an <a>absolute IRI</a> or <a>keyword</a> other
      than <code>@set</code>, <code>@context</code>, and <code>@index</code>.
      Please note that the <code>@index</code> key will be ignored when being processed.</p>

    <p>In both cases, the value associated with the keys <code>@list</code> and <code>@set</code>
      MUST be one of the following types:</p>
    <ul>
      <li><a>string</a>,</li>
      <li><a>number</a>,</li>
      <li><a>true</a>,</li>
      <li><a>false</a>,</li>
      <li><a>null</a>,</li>
      <li><a>node object</a>,</li>
      <li><a>value object</a>, or</li>
      <li>an <a>array</a> of zero or more of the above possibilities</li>
    </ul>

    <p>See <a class="sectionRef" href="#sets-and-lists"></a> for further discussion on sets and lists.</p>
  </section>

  <section class="normative">
    <h2>Language Maps</h2>

    <p>A <a>language map</a> is used to associate a language with a value in a
      way that allows easy programmatic access. A <a>language map</a> may be
      used as a term value within a <a>node object</a> if the <a>term</a> is defined
      with <code>@container</code> set to <code>@language</code>,
      <span class="changed">
        or an array containing both <code>@language</code> and <code>@set</code>
      </span>. The keys of a
      <a>language map</a> MUST be <a>strings</a> representing
      [[BCP47]] language codes, the <a>keyword</a> <code>@none</code>,
      or a <a>term</a> which expands to <code>@none</code>,
      and the values MUST be any of the following types:</p>

    <ul>
      <li><a>null</a>,</li>
      <li><a>string</a>, or</li>
      <li>an <a>array</a> of zero or more of the <a>strings</a></li>
    </ul>

    <p>See <a class="sectionRef" href="#string-internationalization"></a> for further discussion
      on language maps.</p>
  </section>

  <section class="normative">
    <h2>Index Maps</h2>

    <p>An <a>index map</a> allows keys that have no semantic meaning,
      but should be preserved regardless, to be used in JSON-LD documents.
      An <a>index map</a> may
      be used as a <a>term</a> value within a <a>node object</a> if the
      term is defined with <code>@container</code> set to <code>@index</code>,
      <span class="changed">
        or an array containing both <code>@index</code> and <code>@set</code>
      </span>.
      The values of the members of an <a>index map</a> MUST be one
      of the following types:</p>

    <ul>
      <li><a>string</a>,</li>
      <li><a>number</a>,</li>
      <li><a>true</a>,</li>
      <li><a>false</a>,</li>
      <li><a>null</a>,</li>
      <li><a>node object</a>,</li>
      <li><a>value object</a>,</li>
      <li><a>list object</a>,</li>
      <li><a>set object</a>,</li>
      <li>an <a>array</a> of zero or more of the above possibilities</li>
    </ul>

    <p>See <a class="sectionRef" href="#data-indexing"></a> for further information on this topic.</p>

    <p class="changed"><a>Index Maps</a> may also be used to map indexes to associated
      <a>named graphs</a>, if the term is defined with <code>@container</code>
      set to an array containing both <code>@graph</code> and
      <code>@index</code>, and optionally including <code>@set</code>. The
      value consists of the <a>node objects</a> contained within the <a>named
      graph</a> which is named using the referencing key, which can be
      represented as a <a>simple graph object</a>.</p>
  </section>

  <section class="changed">
    <h2>Id Maps</h2>

    <p>An <a>id map</a> is used to associate an <a>IRI</a> with a value that allows easy
      programmatic access. An <a>id map</a> may be used as a term value within a <a>node object</a> if the <a>term</a>
      is defined with <code>@container</code> set to <code>@id</code>,
      or an array containing both <code>@id</code> and <code>@set</code>.
      The keys of an <a>id map</a> MUST be <a>IRIs</a>
      (<a>relative IRI</a>, <a>compact IRI</a> (including <a>blank node identifiers</a>), or <a>absolute IRI</a>),
      the <a>keyword</a> <code>@none</code>,
      or a <a>term</a> which expands to <code>@none</code>,
      and the values MUST be <a>node objects</a>.</p>

    <p>If the value contains a property expanding to <code>@id</code>, it's value MUST
      be equivalent to the referencing key. Otherwise, the property from the value is used as
      the <code>@id</code> of the <a>node object</a> value when expanding.</p>

    <p><a>Id Maps</a> may also be used to map <a>graph names</a> to their
      <a>named graphs</a>, if the term is defined with <code>@container</code>
      set to an array containing both <code>@graph</code> and <code>@id</code>,
      and optionally including <code>@set</code>. The value consists of the
      <a>node objects</a> contained within the <a>named graph</a>
      which is named using the referencing key.</p>
  </section>

  <section class="changed">
    <h2>Type Maps</h2>

    <p>A <a>type map</a> is used to associate an <a>IRI</a> with a value that allows easy
      programmatic access. A <a>type map</a> may be used as a term value within a <a>node object</a> if the <a>term</a>
      is defined with <code>@container</code> set to <code>@type</code>,
      or an array containing both <code>@type</code> and <code>@set</code>.
      The keys of a <a>type map</a> MUST be <a>IRIs</a>
      (<a>relative IRI</a>, <a>compact IRI</a> (including <a>blank node identifiers</a>), or <a>absolute IRI</a>),
      the <a>keyword</a> <code>@none</code>,
      or a <a>term</a> which expands to <code>@none</code>,
      and the values MUST be <a>node objects</a>.</p>

    <p>If the value contains a property expanding to <code>@type</code>, and it's value
      is contains the referencing key after suitable expansion of both the referencing key
      and the value, then the <a>node object</a> already contains the type. Otherwise, the property from the value is
      added as a <code>@type</code> of the <a>node object</a> value when expanding.</p>
  </section>

  <section class="changed">
    <h2>Property Nesting</h2>

    <p>A <a>nested property</a> is used to gather <a>properties</a> of a <a>node object</a> in a separate
      <a>JSON object</a>, or <a>array</a> of <a>JSON objects</a> which are not
      <a>value objects</a>. It is semantically transparent and is removed
      during the process of <a>expansion</a>. Property nesting is recursive, and
      collections of nested properties may contain further nesting.</p>

    <p>Semantically, nesting is treated as if the properties and values were declared directly
      within the containing <a>node object</a>.</p>
  </section>

<section class="normative">
  <h2>Context Definitions</h2>

  <p>A <dfn>context definition</dfn> defines a <a>local context</a> in a
    <a>node object</a>.</p>

  <p>A <a>context definition</a> MUST be a <a>JSON object</a> whose
    keys MUST be either <a>terms</a>, <a>compact IRIs</a>, <a>absolute IRIs</a>,
    or one of the <a>keywords</a> <code>@language</code>, <code>@base</code>,
    <code>@vocab</code>, or <code class="changed">@version</code>.</p>

  <p>If the <a>context definition</a> has an <code>@language</code> key,
    its value MUST have the <a data-cite="BCP47#section-2.1.1">lexical form</a> described in [[!BCP47]] or be <a>null</a>.</p>

  <p>If the <a>context definition</a> has an <code>@base</code> key,
    its value MUST be an <a>absolute IRI</a>, a <a>relative IRI</a>,
    or <a>null</a>.</p>

  <p>If the <a>context definition</a> has an <code>@vocab</code> key,
    its value MUST be a <a>absolute IRI</a>, a <a>compact IRI</a>,
    a <a>blank node identifier</a>,
    <span class="changed">an empty string (<code>&quot;&quot;</code>)</span>,
    a <a>term</a>, or <a>null</a>.</p>

  <p class="changed">If the <a>context definition</a> has an <code>@version</code> key,
    its value MUST be a <a>number</a> with the value <code>1.1</code>.</p>

  <p>The value of keys that are not <a>keywords</a> MUST be either an
    <a>absolute IRI</a>, a <a>compact IRI</a>, a <a>term</a>,
    a <a>blank node identifier</a>, a <a>keyword</a>, <a>null</a>,
    or an <a>expanded term definition</a>.</p>

  <p>An <a>expanded term definition</a> is used to describe the mapping
    between a <a>term</a> and its expanded identifier, as well as other
    properties of the value associated with the <a>term</a> when it is
    used as key in a <a>node object</a>.</p>

  <p>An <a>expanded term definition</a> MUST be a <a>JSON object</a>
    composed of zero or more keys from
    <code>@id</code>,
    <code>@reverse</code>,
    <code>@type</code>,
    <code>@language</code>,
    <code class="changed">@context</code>,
    <code class="changed">@prefix</code>, or
    <code>@container</code>. An
    <a>expanded term definition</a> SHOULD NOT contain any other keys.</p>

  <p>If the term being defined is not a <a>compact IRI</a> or
    <a>absolute IRI</a> and the <a>active context</a> does not have an
    <code>@vocab</code> mapping, the <a>expanded term definition</a> MUST
    include the <code>@id</code> key.</p>

  <p>If the <a>expanded term definition</a> contains the <code>@id</code>
    <a>keyword</a>, its value MUST be <a>null</a>, an <a>absolute IRI</a>,
    a <a>blank node identifier</a>, a <a>compact IRI</a>, a <a>term</a>,
    or a <a>keyword</a>.</p>

  <p>If an <a>expanded term definition</a> has an <code>@reverse</code> member,
    it MUST NOT have <code>@id</code> or <code>@nest</code> members at the same time,
    its value MUST be an <a>absolute IRI</a>,
    a <a>blank node identifier</a>, a <a>compact IRI</a>, or a <a>term</a>. If an
    <code>@container</code> member exists, its value MUST be <a>null</a>,
    <code>@set</code>, or <code>@index</code>.</p>

  <p>If the <a>expanded term definition</a> contains the <code>@type</code>
    <a>keyword</a>, its value MUST be an <a>absolute IRI</a>, a
    <a>compact IRI</a>, a <a>term</a>, <a>null</a>, or one of the
    <a>keywords</a> <code>@id</code> or <code>@vocab</code>.</p>

  <p>If the <a>expanded term definition</a> contains the <code>@language</code> <a>keyword</a>,
    its value MUST have the <a data-cite="BCP47#section-2.1.1">lexical form</a> described in [[!BCP47]] or be <a>null</a>.</p>

  <p>If the <a>expanded term definition</a> contains the <code>@container</code>
    <a>keyword</a>, its value MUST be either
    <code>@list</code>,
    <code>@set</code>,
    <code>@language</code>,
    <code>@index</code>,
    <span class="changed"><code>@id</code></span>,
    <span class="changed"><code>@graph</code></span>,
    <span class="changed"><code>@type</code></span>, or be
    <a>null</a>
    <span class="changed">
      or an <a>array</a> containing exactly any one of those keywords, or a
      combination of <code>@set</code> and any of <code>@index</code>,
      <code>@id</code>, <code>@graph</code>, <code>@type</code>,
      <code>@language</code> in any order
    </span>.
    <span class="changed"><code>@container</code> may also be an array
      containing <code>@graph</code> along with either <code>@id</code> or
      <code>@index</code> and also optionally including <code>@set</code>.</span>
    If the value
    is <code>@language</code>, when the <a>term</a> is used outside of the
    <code>@context</code>, the associated value MUST be a <a>language map</a>.
    If the value is <code>@index</code>, when the <a>term</a> is used outside of
    the <code>@context</code>, the associated value MUST be an
    <a>index map</a>.</p>

  <p class="changed">If an <a>expanded term definition</a> has an <code>@context</code> member,
    it MUST be a valid <code>context definition</code>.</p>

  <p class="changed">If the <a>expanded term definition</a> contains the <code>@nest</code>
    <a>keyword</a>, its value MUST be either <code>@nest</code>, or a term
    which expands to <code>@nest</code>.</p>

  <p class="changed">If the <a>expanded term definition</a> contains the <code>@prefix</code>
    <a>keyword</a>, its value MUST be <code>true</code> or <code>false</code>.</p>

  <p><a>Terms</a> MUST NOT be used in a circular manner. That is,
    the definition of a term cannot depend on the definition of another term if that other
    term also depends on the first term.</p>

  <p>See <a class="sectionRef" href="#the-context"></a> for further discussion on contexts.</p>
</section>

</section>

<section class="normative">
  <h2>Relationship to RDF</h2>

  <p>JSON-LD is a
    <dfn data-cite="RDF11-CONCEPTS#dfn-concrete-rdf-syntax">concrete RDF syntax</dfn>
    as described in [[RDF11-CONCEPTS]]. Hence, a JSON-LD document is both an
    RDF document <em>and</em> a JSON document and correspondingly represents an
    instance of an RDF data model. However, JSON-LD also extends the RDF data
    model to optionally allow JSON-LD to serialize
    <dfn data-cite="RDF11-CONCEPTS#dfn-generalized-rdf-dataset" data-lt="generalized rdf dataset">generalized RDF Datasets</dfn>.
    The JSON-LD extensions to the RDF data model are:</p>

  <ul>
    <li>In JSON-LD <a>properties</a> can be
      <a>IRIs</a> or <a>blank nodes</a>
      whereas in RDF properties (predicates) have to be <a>IRIs</a>. This
      means that JSON-LD serializes
      <a>generalized RDF Datasets</a>.</li>
    <li>In JSON-LD <a>lists</a> are part of the data model
      whereas in RDF they are part of a vocabulary, namely [[RDF-SCHEMA]].</li>
    <li>RDF values are either typed <em>literals</em>
      (<a>typed values</a>) or
      <a>language-tagged strings</a> whereas
      JSON-LD also supports JSON's native data types, i.e., <a>number</a>,
      <a>strings</a>, and the boolean values <a>true</a>
      and <a>false</a>. The JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]]
      defines the <a data-cite="JSON-LD11CG-API#data-round-tripping">conversion rules</a>
      between JSON's native data types and RDF's counterparts to allow round-tripping.</li>
  </ul>

  <p>Summarized, these differences mean that JSON-LD is capable of serializing any RDF
    graph or dataset and most, but not all, JSON-LD documents can be directly
    interpreted as RDF as described in RDF 1.1 Concepts [[RDF11-CONCEPTS]].</p>

  <p>For authors and developers working with <a>blank nodes</a>
    as <a>properties</a> when deserializing to RDF,
    three potential approaches are suggested:</p>

  <ul>
    <li>If the author is not yet ready to commit to a stable IRI, the
      property should be mapped to an IRI that is documented as unstable.</li>
    <li>If the developer wishes to use <a>blank nodes</a>
      as <a>properties</a> and also wishes to interpret the
      data as a
      <a>generalized RDF Dataset</a>,
      there is an option, <a data-cite="JSON-LD11CG-API#dom-jsonldoptions-producegeneralizedrdf"><em>produce generalized RDF</em></a>, in the
      <a data-cite="JSON-LD11CG-API#deserialize-json-ld-to-rdf-algorithm">Deserialize JSON-LD to RDF algorithm</a> [[JSON-LD11CG-API]] to do so. Note that a
      <a>generalized RDF Dataset</a>
      is an extension of RDF; it does not conform to the RDF standard.</li>
    <li>If the author or developer wishes to use <a>blank nodes</a>
      as <a>properties</a> and wishes to interpret the data
      as a standard (non-generalized)
      <a>RDF Dataset</a>,
      it is possible to losslessly interpret JSON-LD as RDF by transforming
      <a>blank nodes</a> used as
      <a>properties</a> to <a>IRIs</a>,
      by minting new "Skolem IRIs" as per
      <a data-cite="RDF11-CONCEPTS#section-skolemization">Replacing Blank Nodes with IRIs</a>
      of [[RDF11-CONCEPTS]].</li>
  </ul>

  <p>The normative algorithms for interpreting JSON-LD as RDF and serializing
    RDF as JSON-LD are specified in the JSON-LD 1.1 Processing Algorithms and API
    specification [[JSON-LD11CG-API]].</p>

  <p>Even though JSON-LD serializes
    <a>generalized RDF Datasets</a>, it can
    also be used as a <dfn data-cite="RDF11-CONCEPTS#dfn-rdf-source">RDF graph source</dfn>.
    In that case, a consumer MUST only use the default graph and ignore all <a>named graphs</a>.
    This allows servers to expose data in languages such as Turtle and JSON-LD
    using content negotiation.</p>

  <p class="note">Publishers supporting both dataset and graph syntaxes have to ensure that
    the primary data is stored in the default graph to enable consumers that do not support
    datasets to process the information.</p>

  <section class="informative">
    <h3>Serializing/Deserializing RDF</h3>

    <p>The process of serializing RDF as JSON-LD and deserializing JSON-LD to RDF
      depends on executing the algorithms defined in
      <a data-cite="JSON-LD11CG-API#rdf-serialization-deserialization-algorithms">RDF Serialization-Deserialization Algorithms</a>
      in the JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]].
      It is beyond the scope of this document to detail these algorithms any further,
      but a summary of the necessary operations is provided to illustrate the process.</p>

    <p>The procedure to deserialize a JSON-LD document to RDF involves the
      following steps:</p>

    <ol>
      <li>Expand the JSON-LD document, removing any context; this ensures
        that properties, types, and values are given their full representation
        as <a>IRIs</a> and expanded values. <a>Expansion</a>
        is discussed further in <a class="sectionRef" href="#expanded-document-form"></a>.</li>
      <li>Flatten the document, which turns the document into an array of
        <a>node objects</a>. Flattening is discussed
        further in <a class="sectionRef" href="#flattened-document-form"></a>.</li>
      <li>Turn each <a>node object</a> into a series of <a>RDF triples</a>.</li>
    </ol>

    <p>For example, consider the following JSON-LD document in compact form:</p>

    <pre class="example" data-transform="updateExample"
         title="Sample JSON-LD document">
    <!--
    {
      "@context": {
        "name": "http://xmlns.com/foaf/0.1/name",
        "knows": "http://xmlns.com/foaf/0.1/knows"
      },
      "@id": "http://me.markus-lanthaler.com/",
      "name": "Markus Lanthaler",
      "knows": [
        {
          "@id": "http://manu.sporny.org/about#manu",
          "name": "Manu Sporny"
        }, {
          "name": "Dave Longley"
        }
      ]
    }
    -->
    </pre>

    <p>Running the JSON-LD <a data-cite="JSON-LD11CG-API#expansion-algorithm">Expansion</a> and <a data-cite="JSON-LD11CG-API#flattening-algorithm">Flattening</a> algorithms against the
      JSON-LD input document in the example above would result in the
      following output:</p>

    <pre class="example" data-transform="updateExample"
         title="Flattened and expanded form for the previous example">
    <!--
    [
      {
        "@id": "_:b0",
        "http://xmlns.com/foaf/0.1/name": "Dave Longley"
      }, {
        "@id": "http://manu.sporny.org/about#manu",
        "http://xmlns.com/foaf/0.1/name": "Manu Sporny"
      }, {
        "@id": "http://me.markus-lanthaler.com/",
        "http://xmlns.com/foaf/0.1/name": "Markus Lanthaler",
        "http://xmlns.com/foaf/0.1/knows": [
          { "@id": "http://manu.sporny.org/about#manu" },
          { "@id": "_:b0" }
        ]
      }
    ]
    -->
    </pre>

    <p>Deserializing this to RDF now is a straightforward process of turning
      each <a>node object</a> into one or more RDF triples. This can be
      expressed in Turtle as follows:</p>

    <pre class="example" data-transform="updateExample"
         data-content-type="text/turtle"
         title="Turtle representation of expanded/flattened document">
    <!--
    @prefix foaf: <http://xmlns.com/foaf/0.1/> .

    _:b0 foaf:name "Dave Longley" .

    <http://manu.sporny.org/about#manu> foaf:name "Manu Sporny" .

    <http://me.markus-lanthaler.com/> foaf:name "Markus Lanthaler" ;
        foaf:knows <http://manu.sporny.org/about#manu>, _:b0 .
    -->
    </pre>

    <p>The process of serializing RDF as JSON-LD can be thought of as the
      inverse of this last step, creating an expanded JSON-LD document closely
      matching the triples from RDF, using a single <a>node object</a>
      for all triples having a common subject, and a single <a>property</a>
      for those triples also having a common predicate.</p>
  </section>
</section>

<section class="appendix informative">
  <h2>Changes since 1.0 Recommendation of 16 January 2014</h2>
  <ul>
    <li>A context may contain a <code>@version</code> member which is used to set the <a>processing mode</a>.</li>
    <li>An <a>expanded term definition</a> can now have an
      <code>@context</code> property, which defines a <a>context</a> used for values of
      a <a>property</a> identified with such a <a>term</a>.</li>
    <li><code>@container</code> values within an <a>expanded term definition</a> may now
      include <code>@id</code>, <code>@graph</code> and <code>@type</code>, corresponding to <a>id maps</a> and <a>type maps</a>.</li>
    <li>An <a>expanded term definition</a> can now have an
      <code>@nest</code> property, which identifies a term expanding to
      <code>@nest</code> which is used for containing properties using the same
      <code>@nest</code> mapping. When expanding, the values of a property
      expanding to <code>@nest</code> are treated as if they were contained
      within the enclosing <a>node object</a> directly.</li>
    <li>The JSON syntax has been abstracted into an <a>internal representation</a>
      to allow for other serializations that are functionally equivalent
      to JSON.</li>
    <li>Added <a href="#node-identifier-indexing" class="sectionRef"></a> and <a href="#node-type-indexing" class="sectionRef"></a>.</li>
    <li>Both <a>language maps</a> and <a>index maps</a> may legitimately have an <code>@none</code> value, but
      JSON-LD 1.0 only allowed <a>string</a> values. This has been updated
      to allow (and ignore) <code>@null</code> values.</li>
    <li>The value for <code>@container</code> in an <a>expanded term definition</a>
      can also be an <a>array</a> containing any appropriate container
      keyword along with <code>@set</code> (other than <code>@list</code>).
      This allows a way to ensure that such property values will always
      be expressed in <a>array</a> form.</li>
    <li>In JSON-LD 1.1, terms will be chosen as <a>compact IRI</a> prefixes
      when compacting only if
      a <a>simple term definition</a> is used where the value ends with a URI <a data-cite="RFC3986#section-2.2">gen-delim</a> character,
      or if their <a>expanded term definition</a> contains
      a <code>@prefix</code> member with the value <a>true</a>. The 1.0 algorithm has
      been updated to only consider terms that map to a value that ends with a URI
      <a data-cite="RFC3986#section-2.2">gen-delim</a> character.</li>
    <li>Values of properties where the associated <a>term definition</a>
      has <code>@container</code> set to <code>@graph</code> are interpreted as
      <a>implicitly named graphs</a>, where the associated graph name is
      assigned from a new <a>blank node identifier</a>. Other combinations
      include <code>["@container", "@id"]</code>, <code>["@container", "@index"]</code> each also
      may include <code>"@set"</code>, which create maps from the
      graph identifier or index value similar to <a>index maps</a>
      and <a>id maps</a>.</li>
    <li>The empty string (<code>&quot;&quot;</code>) has been added as a possible value for <code>@vocab</code> in
      a context. When this is set, vocabulary-relative IRIs, such as the
      keys of <a>node objects</a>, are expanded or compacted relative
      to the <a>base IRI</a> using string concatenation.</li>
  </ul>
</section>

<section class="appendix informative">
  <h4>Open Issues</h4>
  <p>The following is a list of issues open at the time of publication.</p>
  <p class="issue defer" data-number="246"></p>
  <p class="issue" data-number="316"></p>
  <p class="issue defer" data-number="333"></p>
  <p class="issue defer" data-number="368"></p>
  <p class="issue defer" data-number="371"></p>
  <p class="issue defer" data-number="397"></p>
  <p class="issue defer" data-number="443"></p>
  <p class="issue defer" data-number="491"></p>
  <p class="issue defer" data-number="547"></p>
  <p class="issue defer" data-number="548"></p>
  <p class="issue defer" data-number="583"></p>
  <p class="issue defer" data-number="584"></p>
  <p class="issue defer" data-number="585"></p>
  <p class="issue defer" data-number="590"></p>
  <p class="issue defer" data-number="595"></p>
  <p class="issue defer" data-number="598"></p>
</section>

<section class="appendix informative">
  <h2>Relationship to Other Linked Data Formats</h2>

  <p>The JSON-LD examples below demonstrate how JSON-LD can be used to
    express semantic data marked up in other linked data formats such as Turtle,
    RDFa, Microformats, and Microdata. These sections are merely provided as
    evidence that JSON-LD is very flexible in what it can express across different
    Linked Data approaches.</p>

  <section class="informative">
    <h3>Turtle</h3>

    <p>The following are examples of transforming RDF expressed in Turtle [[TURTLE]]
      into JSON-LD.</p>

    <section>
      <h4>Prefix definitions</h4>

      <p>The JSON-LD context has direct equivalents for the Turtle
        <code>@prefix</code> declaration:</p>

      <pre class="example" data-transform="updateExample"
           data-content-type="text/turtle"
           title="A set of statements serialized in Turtle">
      <!--
      @prefix foaf: <http://xmlns.com/foaf/0.1/> .

      <http://manu.sporny.org/about#manu> a foaf:Person;
        foaf:name "Manu Sporny";
        foaf:homepage <http://manu.sporny.org/> .
      -->
      </pre>

      <pre class="example" data-transform="updateExample"
           title="The same set of statements serialized in JSON-LD">
      <!--
      {
        "@context": {
          "foaf": "http://xmlns.com/foaf/0.1/"
        },
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "foaf:Person",
        "foaf:name": "Manu Sporny",
        "foaf:homepage": { "@id": "http://manu.sporny.org/" }
      }
      -->
      </pre>
    </section>

    <section>
      <h4>Embedding</h4>

      <p>Both Turtle and JSON-LD allow embedding, although Turtle only allows embedding of
        <a>blank nodes</a>.</p>

      <pre class="example" data-transform="updateExample"
           data-content-type="text/turtle"
           title="Embedding in Turtle">
      <!--
      @prefix foaf: <http://xmlns.com/foaf/0.1/> .

      <http://manu.sporny.org/about#manu>
        a foaf:Person;
        foaf:name "Manu Sporny";
        foaf:knows [ a foaf:Person; foaf:name "Gregg Kellogg" ] .
      -->
      </pre>

      <pre class="example" data-transform="updateExample"
           title="Same embedding example in JSON-LD">
      <!--
      {
        "@context": {
          "foaf": "http://xmlns.com/foaf/0.1/"
        },
        "@id": "http://manu.sporny.org/about#manu",
        "@type": "foaf:Person",
        "foaf:name": "Manu Sporny",
        "foaf:knows": {
          "@type": "foaf:Person",
          "foaf:name": "Gregg Kellogg"
        }
      }
      -->
      </pre>
    </section>

    <section>
      <h4>Conversion of native data types</h4>

      <p>In JSON-LD numbers and boolean values are native data types. While Turtle
        has a shorthand syntax to express such values, RDF's abstract syntax requires
        that numbers and boolean values are represented as typed literals. Thus,
        to allow full round-tripping, the JSON-LD 1.1 Processing Algorithms and API specification [[JSON-LD11CG-API]]
        defines conversion rules between JSON-LD's native data types and RDF's
        counterparts. <a>Numbers</a> without fractions are
        converted to <code>xsd:integer</code>-typed literals, numbers with fractions
        to <code>xsd:double</code>-typed literals and the two boolean values
        <a>true</a> and <a>false</a> to a <code>xsd:boolean</code>-typed
        literal. All typed literals are in canonical lexical form.</p>

      <pre class="example" data-transform="updateExample"
           title="JSON-LD using native data types for numbers and boolean values">
      <!--
      {
        "@context": {
          "ex": "http://example.com/vocab#"
        },
        "@id": "http://example.com/",
        "ex:numbers": [ 14, 2.78 ],
        "ex:booleans": [ true, false ]
      }
      -->
      </pre>

      <pre class="example" data-transform="updateExample"
           data-content-type="text/turtle"
           title="Same example in Turtle using typed literals">
      <!--
      @prefix ex: <http://example.com/vocab#> .
      @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

      <http://example.com/>
        ex:numbers "14"^^xsd:integer, "2.78E0"^^xsd:double ;
        ex:booleans "true"^^xsd:boolean, "false"^^xsd:boolean .
      -->
      </pre>

    </section>

    <section>
      <h4>Lists</h4>
      <p>Both JSON-LD and Turtle can represent sequential lists of values.</p>

      <pre class="example" data-transform="updateExample"
           data-content-type="text/turtle"
           title="A list of values in Turtle">
      <!--
      @prefix foaf: <http://xmlns.com/foaf/0.1/> .

      <http://example.org/people#joebob> a foaf:Person;
        foaf:name "Joe Bob";
        foaf:nick ( "joe" "bob" "jaybee" ) .
      -->
      </pre>

      <pre class="example" data-transform="updateExample"
           title="Same example with a list of values in JSON-LD">
      <!--
      {
        "@context": {
          "foaf": "http://xmlns.com/foaf/0.1/"
        },
        "@id": "http://example.org/people#joebob",
        "@type": "foaf:Person",
        "foaf:name": "Joe Bob",
        "foaf:nick": {
          "@list": [ "joe", "bob", "jaybee" ]
        }
      }
      -->
      </pre>
    </section>
  </section>

  <section class="informative">
    <h3>RDFa</h3>

    <p>The following example describes three people with their respective names and
      homepages in RDFa [[RDFA-CORE]].</p>

    <pre class="example nohighlight" data-transform="updateExample"
           data-content-type="text/html"
         title="RDFa fragment that describes three people">
    <!--
    <div ****prefix="foaf: http://xmlns.com/foaf/0.1/"****>
       <ul>
          <li ****typeof="foaf:Person"****>
            <a ****property="foaf:homepage" href="http://example.com/bob/">
              <span property="foaf:name"****>Bob</span>
            </a>
          </li>
          <li ****typeof="foaf:Person"****>
            <a ****property="foaf:homepage" href="http://example.com/eve/">
             <span property="foaf:name"****>Eve</span>
            </a>
          </li>
          <li ****typeof="foaf:Person"****>
            <a ****property="foaf:homepage" href="http://example.com/manu/">
              <span property="foaf:name"****>Manu</span>
            </a>
          </li>
       </ul>
    </div>
    -->
    </pre>

    <p>An example JSON-LD implementation using a single <a>context</a> is
      described below.</p>

    <pre class="example" data-transform="updateExample"
         title="Same description in JSON-LD (context shared among node objects)">
    <!--
    {
      "@context": {
        "foaf": "http://xmlns.com/foaf/0.1/"
      },
      "@graph": [
        {
          "@type": "foaf:Person",
          "foaf:homepage": "http://example.com/bob/",
          "foaf:name": "Bob"
        }, {
          "@type": "foaf:Person",
          "foaf:homepage": "http://example.com/eve/",
          "foaf:name": "Eve"
        }, {
          "@type": "foaf:Person",
          "foaf:homepage": "http://example.com/manu/",
          "foaf:name": "Manu"
        }
      ]
    }
    -->
    </pre>
  </section>

  <section class="informative">
    <h3>Microformats</h3>

    <p>The following example uses a simple Microformats hCard example to express
      how Microformats [[MICROFORMATS]] are represented in JSON-LD.</p>

    <pre class="example" data-transform="updateExample"
           data-content-type="text/html"
         title="HTML fragment with a simple Microformats hCard">
    <!--
    <div class="vcard">
     <a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
    </div>
    -->
    </pre>

    <p>The representation of the hCard expresses the Microformat terms in the
      <a>context</a> and uses them directly for the <code>url</code> and <code>fn</code>
      properties. Also note that the Microformat to JSON-LD processor has
      generated the proper URL type for <code>http://tantek.com/</code>.</p>

    <pre class="example" data-transform="updateExample"
         title="Same hCard representation in JSON-LD">
    <!--
    {
      "@context": {
        "vcard": "http://microformats.org/profile/hcard#vcard",
        "url": {
          "@id": "http://microformats.org/profile/hcard#url",
          "@type": "@id"
        },
        "fn": "http://microformats.org/profile/hcard#fn"
      },
      "@type": "vcard",
      "url": "http://tantek.com/",
      "fn": "Tantek Çelik"
    }
    -->
    </pre>
  </section>

  <section class="informative">
    <h3>Microdata</h3>

    <p>The HTML Microdata [[MICRODATA]] example below expresses book information as
      a Microdata Work item.</p>

    <pre class="example" data-transform="updateExample"
           data-content-type="text/html"
         title="HTML fragments that describes a book using microdata">
    <!--
    <dl itemscope
        itemtype="http://purl.org/vocab/frbr/core#Work"
        itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N">
     <dt>Title</dt>
     <dd><cite itemprop="http://purl.org/dc/terms/title">Just a Geek</cite></dd>
     <dt>By</dt>
     <dd><span itemprop="http://purl.org/dc/terms/creator">Wil Wheaton</span></dd>
     <dt>Format</dt>
     <dd itemprop="http://purl.org/vocab/frbr/core#realization"
         itemscope
         itemtype="http://purl.org/vocab/frbr/core#Expression"
         itemid="http://purl.oreilly.com/products/9780596007683.BOOK">
      <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK">
      Print
     </dd>
     <dd itemprop="http://purl.org/vocab/frbr/core#realization"
         itemscope
         itemtype="http://purl.org/vocab/frbr/core#Expression"
         itemid="http://purl.oreilly.com/products/9780596802189.EBOOK">
      <link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK">
      Ebook
     </dd>
    </dl>
    -->
    </pre>

    <p>Note that the JSON-LD representation of the Microdata information stays
      true to the desires of the Microdata community to avoid contexts and
      instead refer to items by their full <a>IRI</a>.</p>

    <pre class="example" data-transform="updateExample"
         title="Same book description in JSON-LD (avoiding contexts)">
    <!--
    [
      {
        "@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
        "@type": "http://purl.org/vocab/frbr/core#Work",
        "http://purl.org/dc/terms/title": "Just a Geek",
        "http://purl.org/dc/terms/creator": "Whil Wheaton",
        "http://purl.org/vocab/frbr/core#realization":
        [
          "http://purl.oreilly.com/products/9780596007683.BOOK",
          "http://purl.oreilly.com/products/9780596802189.EBOOK"
        ]
      }, {
        "@id": "http://purl.oreilly.com/products/9780596007683.BOOK",
        "@type": "http://purl.org/vocab/frbr/core#Expression",
        "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
      }, {
        "@id": "http://purl.oreilly.com/products/9780596802189.EBOOK",
        "@type": "http://purl.org/vocab/frbr/core#Expression",
        "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
      }
    ]
    -->
    </pre>
  </section>
</section>

<section class="appendix normative">
  <h2>IANA Considerations</h2>

  <p>This section has been submitted to the Internet Engineering Steering
    Group (IESG) for review, approval, and registration with IANA.</p>

  <h3>application/ld+json</h3>
  <dl>
    <dt>Type name:</dt>
    <dd>application</dd>
    <dt>Subtype name:</dt>
    <dd>ld+json</dd>
    <dt>Required parameters:</dt>
    <dd>None</dd>
    <dt>Optional parameters:</dt>
    <dd>
      <dl>
        <dt><code>profile</code></dt>
        <dd>
          <p>A non-empty list of space-separated URIs identifying specific
            constraints or conventions that apply to a JSON-LD document according to [[RFC6906]].
            A profile does not change the semantics of the resource representation
            when processed without profile knowledge, so that clients both with
            and without knowledge of a profiled resource can safely use the same
            representation. The <code>profile</code> parameter MAY be used by
            clients to express their preferences in the content negotiation process.
            If the profile parameter is given, a server SHOULD return a document that
            honors the profiles in the list which are recognized by the server.
            It is RECOMMENDED that profile URIs are dereferenceable and provide
            useful documentation at that URI. For more information and background
            please refer to [[RFC6906]].</p>
          <p>This specification defines three values for the <code>profile</code> parameter.
            To request or specify <a href="#expanded-document-form">expanded JSON-LD document form</a>,
            the URI <code>http://www.w3.org/ns/json-ld#expanded</code> SHOULD be used.
            To request or specify <a href="#compacted-document-form">compacted JSON-LD document form</a>,
            the URI <code>http://www.w3.org/ns/json-ld#compacted</code> SHOULD be used.
            To request or specify <a href="#flattened-document-form">flattened JSON-LD document form</a>,
            the URI <code>http://www.w3.org/ns/json-ld#flattened</code> SHOULD be used.
            Please note that, according [[HTTP11]], the value of the <code>profile</code>
            parameter has to be enclosed in quotes (<code>"</code>) because it contains
            special characters and, if multiple profiles are combined, whitespace.</p>
          <p>When processing the "profile" media type parameter, it is important to
            note that its value contains one or more URIs and not IRIs. In some cases
            it might therefore be necessary to convert between IRIs and URIs as specified in
            <a data-cite="RFC3986#section-5.1">section 3 Relationship between IRIs and URIs</a>
            of [[RFC3987]].</p>
        </dd>
      </dl>
    </dd>
    <dt>Encoding considerations:</dt>
    <dd>See <a data-cite="RFC6839#section-3.1">RFC&nbsp;6839, section 3.1</a>.</dd>
    <dt>Security considerations:</dt>
    <dd>See [[!RFC7159]]
      <p>Since JSON-LD is intended to be a pure data exchange format for
        directed graphs, the serialization SHOULD NOT be passed through a
        code execution mechanism such as JavaScript's <code>eval()</code>
        function to be parsed. An (invalid) document may contain code that,
        when executed, could lead to unexpected side effects compromising
        the security of a system.</p>
      <p>When processing JSON-LD documents, links to remote contexts are
        typically followed automatically, resulting in the transfer of files
        without the explicit request of the user for each one. If remote
        contexts are served by third parties, it may allow them to gather
        usage patterns or similar information leading to privacy concerns.
        Specific implementations, such as the API defined in the
        JSON-LD 1.1 Processing Algorithms and API specification [[!JSON-LD11CG-API]],
        may provide fine-grained mechanisms to control this behavior.</p>
      <p>JSON-LD contexts that are loaded from the Web over non-secure connections,
        such as HTTP, run the risk of being altered by an attacker such that
        they may modify the JSON-LD <a>active context</a> in a way that
        could compromise security. It is advised that any application that
        depends on a remote context for mission critical purposes vet and
        cache the remote context before allowing the system to use it.</p>
      <p>Given that JSON-LD allows the substitution of long IRIs with short terms,
        JSON-LD documents may expand considerably when processed and, in the worst case,
        the resulting data might consume all of the recipient's resources. Applications
        should treat any data with due skepticism.</p>
    </dd>
    <dt>Interoperability considerations:</dt>
    <dd>Not Applicable</dd>
    <dt>Published specification:</dt>
    <dd>http://www.w3.org/TR/json-ld</dd>
    <dt>Applications that use this media type:</dt>
    <dd>Any programming environment that requires the exchange of
      directed graphs. Implementations of JSON-LD have been created for
      JavaScript, Python, Ruby, PHP, and C++.
    </dd>
    <dt>Additional information:</dt>
    <dd>
      <dl>
        <dt>Magic number(s):</dt>
        <dd>Not Applicable</dd>
        <dt>File extension(s):</dt>
        <dd>.jsonld</dd>
        <dt>Macintosh file type code(s):</dt>
        <dd>TEXT</dd>
      </dl>
    </dd>
    <dt>Person &amp; email address to contact for further information:</dt>
    <dd>Manu Sporny &lt;msporny@digitalbazaar.com&gt;</dd>
    <dt>Intended usage:</dt>
    <dd>Common</dd>
    <dt>Restrictions on usage:</dt>
    <dd>None</dd>
    <dt>Author(s):</dt>
    <dd>Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Niklas Lindström</dd>
    <dt>Change controller:</dt>
    <dd>W3C</dd>
  </dl>

  <p>Fragment identifiers used with <a href="#application-ld-json">application/ld+json</a>
    are treated as in RDF syntaxes, as per
    <a data-cite="RDF11-CONCEPTS#section-fragID">RDF 1.1 Concepts and Abstract Syntax</a>
    [[RDF11-CONCEPTS]].</p>
</section>

<section id="security" class="appendix">
  <h3>Security Considerations</h3>
  <p class="ednote">Consider requirements from <a href="https://w3ctag.github.io/security-questionnaire/">Self-Review Questionnaire: Security and Privacy</a>.</p>
  <p>See, <a href="#iana-considerations" class="sectionRef"></a></p>
</section>

<section class="appendix informative">
  <h2>Acknowledgements</h2>

  <p>The authors would like to extend a deep appreciation and the most sincere
    thanks to Mark Birbeck, who contributed foundational concepts
    to JSON-LD via his work on RDFj. JSON-LD uses a number of core concepts
    introduced in RDFj, such as the context as a mechanism to provide an
    environment for interpreting JSON data. Mark had also been very involved in
    the work on RDFa as well. RDFj built upon that work. JSON-LD exists
    because of the work and ideas he started nearly a decade ago in 2004.</p>

  <p>A large amount of thanks goes out to the JSON-LD Community Group
    participants who worked through many of the technical issues on the mailing
    list and the weekly telecons - of special mention are François Daoust,
    Stéphane Corlosquet, Lin Clark, and Zdenko 'Denny' Vrandečić.</p>

  <p>The work of David I. Lehn and Mike Johnson are appreciated for
    reviewing, and performing several early implementations
    of the specification. Thanks also to Ian Davis for this work on RDF/JSON.</p>

  <p>Thanks to the following individuals, in order of their first name, for
    their input on the specification: Adrian Walker, Alexandre Passant,
    Andy Seaborne, Ben Adida, Blaine Cook, Bradley Allen, Brian Peterson,
    Bryan Thompson, Conal Tuohy, Dan Brickley, Danny Ayers, Daniel Leja,
    Dave Reynolds, David Booth, David I. Lehn, David Wood, Dean Landolt,
    Ed Summers, elf Pavlik,
    Eric Prud'hommeaux, Erik Wilde, Fabian Christ, Jon A. Frost, Gavin Carothers,
    Glenn McDonald, Guus Schreiber, Henri Bergius, Jose María Alvarez Rodríguez,
    Ivan Herman, Jack Moffitt, Josh Mandel, KANZAKI Masahide, Kingsley Idehen,
    Kuno Woudt, Larry Garfield, Mark Baker, Mark MacGillivray, Marko Rodriguez,
    Marios Meimaris, Matt Wuerstl,
    Melvin Carvalho, Nathan Rixham, Olivier Grisel, Paolo Ciccarese, Pat Hayes,
    Patrick Logan, Paul Kuykendall, Pelle Braendgaard,
    Peter Patel-Schneider, Peter Williams, Pierre-Antoine Champin,
    Richard Cyganiak, Roy T. Fielding, Sandro Hawke, Simon Grant, Srecko Joksimovic,
    Stephane Fellah, Steve Harris, Ted Thibodeau Jr., Thomas Steiner, Tim Bray,
    Tom Morris, Tristan King, Sergio Fernández, Werner Wilms, and William Waites.</p>
</section>

</body>
</html>
